Re: [RFC PATCH] zsmalloc: make common caches global

[Yosry Ahmed <yosry.ahmed@linux.dev>]

On Thu, Jan 22, 2026 at 12:28:56PM +0900, Sergey Senozhatsky wrote:
> On (26/01/21 23:58), Yosry Ahmed wrote:
> > On Wed, Jan 21, 2026 at 12:41:39PM +0900, Sergey Senozhatsky wrote:
> > > On (26/01/19 13:44), Nhat Pham wrote:
> > > > On Thu, Jan 15, 2026 at 9:53 PM Sergey Senozhatsky
> > > > <senozhatsky@chromium.org> wrote:
> > > > >
> > > > > On (26/01/16 13:48), 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.
> > > > >
> > > > > This is step 1.
> > > > >
> > > > > Step 2 is to look into possibility of sharing zsmalloc pools.
> > > > > E.g. if there are N zram devices in the system, do we really need
> > > > > N zsmalloc pools?  Can we just share a single pool between them?
> > > > 
> > > > Ditto for zswap (although here, we almost always only have a single zswap pool).
> > > 
> > > COMPLETELY UNTESTED (current linux-next doesn't boot for me, hitting
> > > an "Oops: stack guard page: 0000" early during boot).
> > > 
> > > So I'm thinking of something like below.  Basically have a Kconfig
> > > option to turn zsmalloc into a singleton pool mode, transparently
> > > for zsmalloc users.
> > 
> > Why do we need a config option? Is the main concern with a single pool
> > lock contention? If yes, we can probably measure it by spawning many
> > zram devices and stressing them at the same time.
> 
> That's a good question.  I haven't thought about just converting
> zsmalloc to a singleton pool by default.  I don't think I'm
> concerned with lock contention, the thing is we should have the
> same upper boundary contention wise (there are only num_online_cpus()
> tasks that can concurrently access any zsmalloc pool, be it a singleton
> or not).  I certainly will try to measure once I have linux-next booting
> again.
> 
> What was the reason why you allocated many zsmalloc pool in zswap?

IIRC it was actually lock contention, specifically the pool spinlock.
When the change was made to per-class spinlocks, we dropped the multiple
pools:
http://lore.kernel.org/linux-mm/20240617-zsmalloc-lock-mm-everything-v1-0-5e5081ea11b3@linux.dev/.

So having multiple pools does mitigate lock contention in some cases.
Even though the upper boundary might be the same, the actual number of
CPUs contending on the same lock would go down in practice.

While looking for this, I actually found something more interesting. I
did propose more-or-less the same exact patch back when zswap used
multiple pools:
https://lore.kernel.org/all/20240604175340.218175-1-yosryahmed@google.com/.

Seems like Minchan had some concerns back then. I wonder if those still
apply.