similar to: [PATCH v2 00/18] Support non-lru page migration

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.

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

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 >>) >>

Hello, On (03/30/16 16:12), Minchan Kim wrote: [..] > +static int get_zspage_inuse(struct page *first_page) > +{ > + struct zs_meta *m; > + > + VM_BUG_ON_PAGE(!is_first_page(first_page), first_page); > + > + m = (struct zs_meta *)&first_page->mapping; .. > +static void set_zspage_inuse(struct page *first_page, int val) > +{ > + struct zs_meta *m; > + > +

Hello, On (03/30/16 16:12), Minchan Kim wrote: [..] > +static int get_zspage_inuse(struct page *first_page) > +{ > + struct zs_meta *m; > + > + VM_BUG_ON_PAGE(!is_first_page(first_page), first_page); > + > + m = (struct zs_meta *)&first_page->mapping; .. > +static void set_zspage_inuse(struct page *first_page, int val) > +{ > + struct zs_meta *m; > + > +

On 2016/3/11 15:30, Minchan Kim wrote: > For migration, we need to create sub-page chain of zspage > dynamically so this patch factors it out from alloc_zspage. > > As a minor refactoring, it makes OBJ_ALLOCATED_TAG assign > more clear in obj_malloc(it could be another patch but it's > trivial so I want to put together in this patch). > > Signed-off-by: Minchan Kim

On 2016/3/11 15:30, Minchan Kim wrote: > For migration, we need to create sub-page chain of zspage > dynamically so this patch factors it out from alloc_zspage. > > As a minor refactoring, it makes OBJ_ALLOCATED_TAG assign > more clear in obj_malloc(it could be another patch but it's > trivial so I want to put together in this patch). > > Signed-off-by: Minchan Kim

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

Zsmalloc stores first free object's position into first_page->freelist in each zspage. If we change it with object index from first_page instead of location, we could squeeze it into page->mapping because the number of bit we need to store offset is at most 11bit. Signed-off-by: Minchan Kim <minchan at kernel.org> --- mm/zsmalloc.c | 158

Zsmalloc stores first free object's position into first_page->freelist in each zspage. If we change it with object index from first_page instead of location, we could squeeze it into page->mapping because the number of bit we need to store offset is at most 11bit. Signed-off-by: Minchan Kim <minchan at kernel.org> --- mm/zsmalloc.c | 159

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

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 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: