search for: page_idx

..._SKB_FRAGS. >+ * 4) Length of the data fits in current credit space. >+ */ >+ for (seg_idx = 0; seg_idx < iter->nr_segs; seg_idx++) { >+ struct page *user_pages[MAX_SKB_FRAGS]; >+ const struct iovec *iovec; >+ size_t last_frag_len; >+ size_t pages_in_seg; >+ int page_idx; >+ >+ iovec = &iter->iov[seg_idx]; >+ pages_in_seg = iovec->iov_len >> PAGE_SHIFT; >+ >+ if (iovec->iov_len % PAGE_SIZE) { >+ last_frag_len = iovec->iov_len % PAGE_SIZE; >+ pages_in_seg++; >+ } else { >+ last_frag_len = PAGE_SIZE; >+ }...

...ruct page *page; + struct list_head lst; +}; + int extent_readpages(struct extent_io_tree *tree, struct address_space *mapping, struct list_head *pages, unsigned nr_pages, @@ -3557,19 +3562,47 @@ int extent_readpages(struct extent_io_tree *tree, struct bio *bio = NULL; unsigned page_idx; unsigned long bio_flags = 0; + LIST_HEAD(page_pool); + struct pagelst *pagelst = NULL; for (page_idx = 0; page_idx < nr_pages; page_idx++) { struct page *page = list_entry(pages->prev, struct page, lru); prefetchw(&page->flags); list_del(&page->lru); + + if (!...

...> 63fc: e8 00 00 00 00 callq 6401 <zs_compact+0x2b6> > 6401: 48 8b 85 b0 fe ff ff mov -0x150(%rbp),%rax RAX: 2065676162726166 so rax is totally garbage, I think. It means obj_to_head returns garbage because get_first_obj_offset is utter crab because (page_idx / class->pages_per_zspage) was totally wrong. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 6408: f0 0f ba 28 00 lock btsl $0x0,(%rax) <snip> > > Could you test with [zsmalloc: keep first object offset in struct page] > > in mmotm? > > sure, I...

...> 63fc: e8 00 00 00 00 callq 6401 <zs_compact+0x2b6> > 6401: 48 8b 85 b0 fe ff ff mov -0x150(%rbp),%rax RAX: 2065676162726166 so rax is totally garbage, I think. It means obj_to_head returns garbage because get_first_obj_offset is utter crab because (page_idx / class->pages_per_zspage) was totally wrong. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 6408: f0 0f ba 28 00 lock btsl $0x0,(%rax) <snip> > > Could you test with [zsmalloc: keep first object offset in struct page] > > in mmotm? > > sure, I...

...ruct page *page; + struct list_head lst; +}; + int extent_readpages(struct extent_io_tree *tree, struct address_space *mapping, struct list_head *pages, unsigned nr_pages, @@ -3557,19 +3562,51 @@ int extent_readpages(struct extent_io_tree *tree, struct bio *bio = NULL; unsigned page_idx; unsigned long bio_flags = 0; + LIST_HEAD(page_pool); + struct pagelst *pagelst = NULL; for (page_idx = 0; page_idx < nr_pages; page_idx++) { struct page *page = list_entry(pages->prev, struct page, lru); + bool delay_read = true; prefetchw(&page->flags); list_del(&am...

On (06/16/16 11:58), Minchan Kim wrote: [..] > RAX: 2065676162726166 so rax is totally garbage, I think. > It means obj_to_head returns garbage because get_first_obj_offset is > utter crab because (page_idx / class->pages_per_zspage) was totally > wrong. > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > 6408: f0 0f ba 28 00 lock btsl $0x0,(%rax) > > <snip> > > > > Could you test with [zsmalloc: keep first object offset in struct page]...

Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a BUG() on startup: kernel BUG at include/linux/scatterlist.h:187! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30 Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019 RIP: 0010:sg_init_one+0x85/0xa0 Code: 69 88 32 01 83 e1 03

On Thu, Jun 16, 2016 at 01:23:43PM +0900, Sergey Senozhatsky wrote: > On (06/16/16 11:58), Minchan Kim wrote: > [..] > > RAX: 2065676162726166 so rax is totally garbage, I think. > > It means obj_to_head returns garbage because get_first_obj_offset is > > utter crab because (page_idx / class->pages_per_zspage) was totally > > wrong. > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > 6408: f0 0f ba 28 00 lock btsl $0x0,(%rax) > > > > <snip> > > > > > > Could you test with [zsmalloc:...

On Thu, Jun 16, 2016 at 01:23:43PM +0900, Sergey Senozhatsky wrote: > On (06/16/16 11:58), Minchan Kim wrote: > [..] > > RAX: 2065676162726166 so rax is totally garbage, I think. > > It means obj_to_head returns garbage because get_first_obj_offset is > > utter crab because (page_idx / class->pages_per_zspage) was totally > > wrong. > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > 6408: f0 0f ba 28 00 lock btsl $0x0,(%rax) > > > > <snip> > > > > > > Could you test with [zsmalloc:...

...mBitmapSize(const wxSize& size); + virtual void SetTabCtrlHeight(int height); + + bool AddPage(wxWindow* page, + const wxString& caption, + bool select = false, + const wxBitmap& bitmap = wxNullBitmap); + + bool InsertPage(size_t page_idx, + wxWindow* page, + const wxString& caption, + bool select = false, + const wxBitmap& bitmap = wxNullBitmap); + + bool DeletePage(size_t page); + bool RemovePage(size_t page); + + size_t GetPageCount()...

...age change event. + +h3(#AuiNotebook_getartprovider). AuiNotebook#get_art_provider + + "AuiTabArt":auitabart.html *get_art_provider*() + +Returns the associated art provider. + +h3(#AuiNotebook_getpage). AuiNotebook#get_page + + "Window":window.html *get_page*(%(arg-type)size_t% page_idx) + +Returns the page specified by the given index. + +h3(#AuiNotebook_getpagebitmap). AuiNotebook#get_page_bitmap + + "Bitmap":bitmap.html *get_page_bitmap*(%(arg-type)size_t% page) + +Returns the tab bitmap for the page. + +h3(#AuiNotebook_getpagecount). AuiNotebook#get_page_count + + si...

Hi Sergey, On Wed, Jun 15, 2016 at 04:59:09PM +0900, Sergey Senozhatsky wrote: > Hello Minchan, > > -next 4.7.0-rc3-next-20160614 > > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory access > [ 315.146546] general protection fault: 0000 [#1] PREEMPT SMP KASAN > [ 315.146576] Modules

Hi Sergey, On Wed, Jun 15, 2016 at 04:59:09PM +0900, Sergey Senozhatsky wrote: > Hello Minchan, > > -next 4.7.0-rc3-next-20160614 > > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory access > [ 315.146546] general protection fault: 0000 [#1] PREEMPT SMP KASAN > [ 315.146576] Modules

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.