From: Yosry Ahmed <yosry.ahmed@linux.dev>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Minchan Kim <minchan@kernel.org>, Nhat Pham <nphamcs@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Brian Geffon <bgeffon@google.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH] zsmalloc: make common caches global
Date: Wed, 21 Jan 2026 01:30:07 +0000 [thread overview]
Message-ID: <j6tlqyecmcf7anevhvptoh6lis6hzigencccjpq2j5uy2rax52@fytgstv37ynr> (raw)
In-Reply-To: <a5jkb4d2xolobcddbac6enh2vjdbi3u6wtwfavo2h4ps2iietq@63nnefjw622b>
On Sat, Jan 17, 2026 at 11:24:01AM +0900, Sergey Senozhatsky wrote:
> On (26/01/16 20:49), Yosry Ahmed wrote:
> > On Fri, Jan 16, 2026 at 01:48:41PM +0900, Sergey Senozhatsky wrote:
> > > Currently, zsmalloc creates kmem_cache of handles and zspages
> > > for each pool, which may be suboptimal from the memory usage
> > > point of view (extra internal fragmentation per pool). Systems
> > > that create multiple zsmalloc pools may benefit from shared
> > > common zsmalloc caches.
> >
> > I had a similar patch internally when we had 32 zsmalloc pools with
> > zswap.
>
> Oh, nice.
>
> > You can calculate the savings by using /proc/slabinfo. The unused memory
> > is (num_objs-active_objs)*objsize. You can sum this across all caches
> > when you have multiple pools, and compare it to the unused memory with a
> > single cache.
>
> Right. Just curious, do you recall any numbers?
I have the exact numbers actually, from /proc/slabinfo while running a
zswap (internal) test:
*** Before:
# name <active_objs> <num_objs> <objsize> ..
zs_handle 35637 35760 16 ...
zs_handle 35577 35760 16 ...
zs_handle 35638 35760 16 ...
zs_handle 35700 35760 16 ...
zs_handle 35937 36240 16 ...
zs_handle 35518 35760 16 ...
zs_handle 35700 36000 16 ...
zs_handle 35517 35760 16 ...
zs_handle 35818 36000 16 ...
zs_handle 35698 35760 16 ...
zs_handle 35536 35760 16 ...
zs_handle 35877 36240 16 ...
zs_handle 35757 36000 16 ...
zs_handle 35760 36000 16 ...
zs_handle 35820 36000 16 ...
zs_handle 35999 36000 16 ...
zs_handle 35700 36000 16 ...
zs_handle 35817 36000 16 ...
zs_handle 35698 36000 16 ...
zs_handle 35699 36000 16 ...
zs_handle 35580 35760 16 ...
zs_handle 35578 35760 16 ...
zs_handle 35820 36000 16 ...
zs_handle 35517 35760 16 ...
zs_handle 35700 36000 16 ...
zs_handle 35640 35760 16 ...
zs_handle 35820 36000 16 ...
zs_handle 35578 35760 16 ...
zs_handle 35578 35760 16 ...
zs_handle 35817 36000 16 ...
zs_handle 35518 35760 16 ...
zs_handle 35940 36240 16 ...
zspage 991 1079 48 ...
zspage 936 996 48 ...
zspage 940 996 48 ...
zspage 1050 1079 48 ...
zspage 973 1079 48 ...
zspage 942 996 48 ...
zspage 1065 1162 48 ...
zspage 885 996 48 ...
zspage 887 913 48 ...
zspage 1053 1079 48 ...
zspage 983 996 48 ...
zspage 966 996 48 ...
zspage 970 1079 48 ...
zspage 880 913 48 ...
zspage 1006 1079 48 ...
zspage 998 1079 48 ...
zspage 1129 1162 48 ...
zspage 903 913 48 ...
zspage 833 996 48 ...
zspage 861 913 48 ...
zspage 764 913 48 ...
zspage 898 913 48 ...
zspage 973 1079 48 ...
zspage 945 996 48 ...
zspage 943 1079 48 ...
zspage 1024 1079 48 ...
zspage 820 913 48 ...
zspage 702 830 48 ...
zspage 1049 1079 48 ...
zspage 990 1162 48 ...
zspage 988 1079 48 ...
zspage 932 996 48 ...
Unused memory = $(awk '{s += $4*($3-$2)} END {print s}') = 218416 bytes
*** After:
# name <active_objs> <num_objs> <objsize> ..
zs_handle 1054440 1054800 16 ...
zspage 5720 5810 48 ...
Unused memory = (1054800-1054440)*16 + (5810-5720)*48 = 10080 bytes
That was about ~20 times reduction in waste when using 32 pools with
zswap. I suspect we wouldn't be using that many pools with zram.
>
> [..]
> > Hmm instead of the repeated kmem_cache_destroy() calls, can we do sth
> > like this:
>
> Sure.
next prev parent reply other threads:[~2026-01-21 1:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 4:48 Sergey Senozhatsky
2026-01-16 5:52 ` Sergey Senozhatsky
2026-01-19 21:44 ` Nhat Pham
2026-01-21 3:41 ` Sergey Senozhatsky
2026-01-21 23:58 ` Yosry Ahmed
2026-01-22 3:28 ` Sergey Senozhatsky
2026-01-22 3:39 ` Yosry Ahmed
2026-01-22 3:55 ` Sergey Senozhatsky
2026-01-16 20:49 ` Yosry Ahmed
2026-01-17 2:24 ` Sergey Senozhatsky
2026-01-21 1:30 ` Yosry Ahmed [this message]
2026-01-21 1:56 ` Sergey Senozhatsky
2026-01-19 21:43 ` Nhat Pham
2026-01-20 1:19 ` Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=j6tlqyecmcf7anevhvptoh6lis6hzigencccjpq2j5uy2rax52@fytgstv37ynr \
--to=yosry.ahmed@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=bgeffon@google.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=nphamcs@gmail.com \
--cc=senozhatsky@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox