search for: zs_malloc

...e Signed-off-by: Minchan Kim <minchan at kernel.org> --- mm/zsmalloc.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index 156edf909046..b4fb11831acb 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -1435,8 +1435,7 @@ unsigned long zs_malloc(struct zs_pool *pool, size_t size) } EXPORT_SYMBOL_GPL(zs_malloc); -static void obj_free(struct zs_pool *pool, struct size_class *class, - unsigned long obj) +static void obj_free(struct size_class *class, unsigned long obj) { struct link_free *link; struct page *first_page, *f_page; @@...

...800a7caab00 ffff8800a7caab58 [ 344.264196] Call Trace: [ 344.264199] [<ffffffff814eeb8c>] __delay+0xa/0xc [ 344.264203] [<ffffffff81127ce6>] do_raw_spin_lock+0x197/0x257 [ 344.264206] [<ffffffff81d32d0d>] _raw_spin_lock+0x35/0x3c [ 344.264212] [<ffffffffa03ccd78>] ? zs_malloc+0x17e/0xb71 [zsmalloc] [ 344.264217] [<ffffffffa03ccd78>] zs_malloc+0x17e/0xb71 [zsmalloc] [ 344.264220] [<ffffffffa0190204>] ? lzo_decompress+0x11d/0x11d [lzo] [ 344.264223] [<ffffffff81122faf>] ? lock_acquire+0xec/0x147 [ 344.264228] [<ffffffffa03ccbfa>] ? obj_mall...

...c unsigned long obj_malloc(struct page *first_page, - struct size_class *class, unsigned long handle) +static unsigned long obj_malloc(struct size_class *class, + struct page *first_page, unsigned long handle) { unsigned long obj; struct link_free *link; @@ -1423,7 +1425,7 @@ unsigned long zs_malloc(struct zs_pool *pool, size_t size) class->size, class->pages_per_zspage)); } - obj = obj_malloc(first_page, class, handle); + obj = obj_malloc(class, first_page, handle); /* Now move the zspage to another fullness group, if required */ fix_fullness_group(class, first_page); rec...

This patch enables tail page migration of zspage. In this point, I tested zsmalloc regression with micro-benchmark which does zs_malloc/map/unmap/zs_free for all size class in every CPU(my system is 12) during 20 sec. It shows 1% regression which is really small when we consider the benefit of this feature and realworkload overhead(i.e., most overhead comes from compression). Signed-off-by: Minchan Kim <minchan at kernel.org&g...

Hi Minchan, [auto build test WARNING on next-20160318] [cannot apply to v4.5-rc7 v4.5-rc6 v4.5-rc5 v4.5] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160321-143339 coccinelle warnings: (new ones prefixed by >>) >>

Hi Minchan, [auto build test WARNING on next-20160318] [cannot apply to v4.5-rc7 v4.5-rc6 v4.5-rc5 v4.5] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160321-143339 coccinelle warnings: (new ones prefixed by >>) >>

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.