search for: zs_empti

Hello Minchan, On (03/30/16 16:12), Minchan Kim wrote: [..] > @@ -1835,23 +1827,31 @@ static void __zs_compact(struct zs_pool *pool, struct size_class *class) > if (!migrate_zspage(pool, class, &cc)) > break; > > - putback_zspage(pool, class, dst_page); > + VM_BUG_ON_PAGE(putback_zspage(pool, class, > + dst_page) == ZS_EMPTY, dst_page); can this

Hello Minchan, On (03/30/16 16:12), Minchan Kim wrote: [..] > @@ -1835,23 +1827,31 @@ static void __zs_compact(struct zs_pool *pool, struct size_class *class) > if (!migrate_zspage(pool, class, &cc)) > break; > > - putback_zspage(pool, class, dst_page); > + VM_BUG_ON_PAGE(putback_zspage(pool, class, > + dst_page) == ZS_EMPTY, dst_page); can this

Currently, putback_zspage does free zspage under class->lock if fullness become ZS_EMPTY but it makes trouble to implement locking scheme for new zspage migration. So, this patch is to separate free_zspage from putback_zspage and free zspage out of class->lock which is preparation for zspage migration. Signed-off-by: Minchan Kim <minchan at kernel.org> --- mm/zsmalloc.c | 46

Hi Sergey, On Mon, Apr 18, 2016 at 10:04:08AM +0900, Sergey Senozhatsky wrote: > Hello Minchan, > > On (03/30/16 16:12), Minchan Kim wrote: > [..] > > @@ -1835,23 +1827,31 @@ static void __zs_compact(struct zs_pool *pool, struct size_class *class) > > if (!migrate_zspage(pool, class, &cc)) > > break; > > > > - putback_zspage(pool, class,

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.

Currently, we store class:fullness into page->mapping. The number of class we can support is 255 and fullness is 4 so (8 + 2 = 10bit) is enough to represent them. Meanwhile, the bits we need to store in-use objects in zspage is that 11bit is enough. For example, If we assume that 64K PAGE_SIZE, class_size 32 which is worst case, class->pages_per_zspage become 1 so the number of objects in

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.

On 2016/3/11 15:30, Minchan Kim wrote: > Every zspage in a size_class has same number of max objects so > we could move it to a size_class. > > Signed-off-by: Minchan Kim <minchan at kernel.org> > --- > mm/zsmalloc.c | 29 ++++++++++++++--------------- > 1 file changed, 14 insertions(+), 15 deletions(-) > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c > index

On 2016/3/11 15:30, Minchan Kim wrote: > Every zspage in a size_class has same number of max objects so > we could move it to a size_class. > > Signed-off-by: Minchan Kim <minchan at kernel.org> > --- > mm/zsmalloc.c | 29 ++++++++++++++--------------- > 1 file changed, 14 insertions(+), 15 deletions(-) > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c > index

Let's remove unused pool param in obj_free 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) }

Every zspage in a size_class has same number of max objects so we could move it to a size_class. Signed-off-by: Minchan Kim <minchan at kernel.org> --- mm/zsmalloc.c | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index b4fb11831acb..ca663c82c1fc 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -32,8 +32,6

Every zspage in a size_class has same number of max objects so we could move it to a size_class. Signed-off-by: Minchan Kim <minchan at kernel.org> --- mm/zsmalloc.c | 32 +++++++++++++++----------------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index a0890e9003e2..8649d0243e6c 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -32,8

On Sat, Mar 12, 2016 at 09:44:48AM +0800, xuyiping wrote: > > > On 2016/3/11 15:30, Minchan Kim wrote: > >Every zspage in a size_class has same number of max objects so > >we could move it to a size_class. > > > >Signed-off-by: Minchan Kim <minchan at kernel.org> > >--- > > mm/zsmalloc.c | 29 ++++++++++++++--------------- > > 1 file

This patch cleans up function parameter "struct page". Many functions of zsmalloc expects that page paramter is "first_page" so use "first_page" rather than "page" for code readability. Signed-off-by: Minchan Kim <minchan at kernel.org> --- mm/zsmalloc.c | 62 ++++++++++++++++++++++++++++++----------------------------- 1 file changed, 32

This patch cleans up function parameter ordering to order higher data structure first. Signed-off-by: Minchan Kim <minchan at kernel.org> --- mm/zsmalloc.c | 50 ++++++++++++++++++++++++++------------------------ 1 file changed, 26 insertions(+), 24 deletions(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index 3c82011cc405..156edf909046 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@

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: