On Wed, Jun 30, 2021 at 06:52:58PM -0700, Andrew Morton wrote: > From: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx> > Subject: mm: zram: amend SLAB_RECLAIM_ACCOUNT on zspage_cachep > > Zspage_cachep is found be merged with other kmem cache during test, which > is not good for debug things (zs_pool->zspage_cachep present to be another > kmem cache in memory dumpfile). It is also neccessary to do so as > shrinker has been registered for zspage. > > Amending this flag can help kernel to calculate SLAB_RECLAIMBLE correctly. > > Link: https://lkml.kernel.org/r/1623137297-29685-1-git-send-email-huangzhaoyang@xxxxxxxxx > Signed-off-by: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx> > Cc: Minchan Kim <minchan@xxxxxxxxxx> > Cc: Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx> > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> Sorry for the late. I don't think this is correct. It's true "struct zspage" can be freed by zsmalloc's compaction registerred by slab shrinker so tempted to make it SLAB_RECLAIM_ACCOUNT. However, it's quite limited to work only when objects in the zspage are heavily fragmented. Once the compaction is done, zspage are never discardable until objects are fragmented again. It means it could hurt other reclaimable slab page reclaiming since the zspage slab object pins the page. > --- > > mm/zsmalloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- a/mm/zsmalloc.c~mm-zram-amend-slab_reclaim_account-on-zspage_cachep > +++ a/mm/zsmalloc.c > @@ -328,7 +328,7 @@ static int create_cache(struct zs_pool * > return 1; > > pool->zspage_cachep = kmem_cache_create("zspage", sizeof(struct zspage), > - 0, 0, NULL); > + 0, SLAB_RECLAIM_ACCOUNT, NULL); > if (!pool->zspage_cachep) { > kmem_cache_destroy(pool->handle_cachep); > pool->handle_cachep = NULL; > _
