search for: isolate_freepages_block

...000069a1246f660 000000000000069a ffff880005114000 ffffea0002ff0180 [ 315.147143] Call Trace: [ 315.147154] [<ffffffffa02c3de8>] ? obj_to_head+0x9d/0x9d [zsmalloc] [ 315.147175] [<ffffffff81d31dbc>] ? _raw_spin_unlock_irqrestore+0x47/0x5c [ 315.147195] [<ffffffff812275b1>] ? isolate_freepages_block+0x2f9/0x5a6 [ 315.147213] [<ffffffff8127f15c>] ? kasan_poison_shadow+0x2f/0x31 [ 315.147230] [<ffffffff8127f66a>] ? kasan_alloc_pages+0x39/0x3b [ 315.147246] [<ffffffff812267e6>] ? map_pages+0x1f3/0x3ad [ 315.147262] [<ffffffff812265f3>] ? update_pageblock_skip+0x18d...

...t; Could you revert [1] and retest? > > > > [1] mm/compaction: split freepages without holding the zone lock > > ok, so this is not related to zsmalloc. finally manged to reproduce > it. will fork a separate thread. The reason I mentioned [1] is that it seems to have a bug. isolate_freepages_block __isolate_free_page if(!zone_watermark_ok()) return 0; list_add_tail(&page->lru, freelist); However, the page is not isolated. Joonsoo?

...t; Could you revert [1] and retest? > > > > [1] mm/compaction: split freepages without holding the zone lock > > ok, so this is not related to zsmalloc. finally manged to reproduce > it. will fork a separate thread. The reason I mentioned [1] is that it seems to have a bug. isolate_freepages_block __isolate_free_page if(!zone_watermark_ok()) return 0; list_add_tail(&page->lru, freelist); However, the page is not isolated. Joonsoo?

...00000000069a ffff880005114000 ffffea0002ff0180 > [ 315.147143] Call Trace: > [ 315.147154] [<ffffffffa02c3de8>] ? obj_to_head+0x9d/0x9d [zsmalloc] > [ 315.147175] [<ffffffff81d31dbc>] ? _raw_spin_unlock_irqrestore+0x47/0x5c > [ 315.147195] [<ffffffff812275b1>] ? isolate_freepages_block+0x2f9/0x5a6 > [ 315.147213] [<ffffffff8127f15c>] ? kasan_poison_shadow+0x2f/0x31 > [ 315.147230] [<ffffffff8127f66a>] ? kasan_alloc_pages+0x39/0x3b > [ 315.147246] [<ffffffff812267e6>] ? map_pages+0x1f3/0x3ad > [ 315.147262] [<ffffffff812265f3>] ? update_...

...00000000069a ffff880005114000 ffffea0002ff0180 > [ 315.147143] Call Trace: > [ 315.147154] [<ffffffffa02c3de8>] ? obj_to_head+0x9d/0x9d [zsmalloc] > [ 315.147175] [<ffffffff81d31dbc>] ? _raw_spin_unlock_irqrestore+0x47/0x5c > [ 315.147195] [<ffffffff812275b1>] ? isolate_freepages_block+0x2f9/0x5a6 > [ 315.147213] [<ffffffff8127f15c>] ? kasan_poison_shadow+0x2f/0x31 > [ 315.147230] [<ffffffff8127f66a>] ? kasan_alloc_pages+0x39/0x3b > [ 315.147246] [<ffffffff812267e6>] ? map_pages+0x1f3/0x3ad > [ 315.147262] [<ffffffff812265f3>] ? update_...

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and easy fork fail. The problem was fragmentation caused by zram and GPU driver mainly. With memory pressure, their pages were spread out all of pageblock and it cannot be migrated with current compaction algorithm which supports only LRU pages. In the end, compaction cannot

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and easy fork fail. The problem was fragmentation caused by zram and GPU driver mainly. With memory pressure, their pages were spread out all of pageblock and it cannot be migrated with current compaction algorithm which supports only LRU pages. In the end, compaction cannot

On Thu, Jun 16, 2016 at 02:22:09PM +0900, Sergey Senozhatsky wrote: > On (06/16/16 13:47), Minchan Kim wrote: > [..] > > > this is what I'm getting with the [zsmalloc: keep first object offset in struct page] > > > applied: "count:0 mapcount:-127". which may be not related to zsmalloc at this point. > > > > > > kernel: BUG: Bad page state

On Thu, Jun 16, 2016 at 02:22:09PM +0900, Sergey Senozhatsky wrote: > On (06/16/16 13:47), Minchan Kim wrote: > [..] > > > this is what I'm getting with the [zsmalloc: keep first object offset in struct page] > > > applied: "count:0 mapcount:-127". which may be not related to zsmalloc at this point. > > > > > > kernel: BUG: Bad page state