[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <qs7qfzsldjz4fd3lozlm72p2vmebzxvsxos76r2h4gvjc555un@3mfigywcnenv>
Date: Tue, 20 Jan 2026 10:19:13 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Nhat Pham <nphamcs@...il.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>, Yosry Ahmed <yosry.ahmed@...ux.dev>,
Minchan Kim <minchan@...nel.org>, Johannes Weiner <hannes@...xchg.org>,
Brian Geffon <bgeffon@...gle.com>, linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC PATCH] zsmalloc: make common caches global
On (26/01/19 13:43), Nhat Pham wrote:
> On Thu, Jan 15, 2026 at 8:49 PM Sergey Senozhatsky
> <senozhatsky@...omium.org> 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.
> >
> > Make handles and zspages kmem caches global.
>
> Hmm yeah this sounds reasonable to me. No reason to have dedicated
> kmem_cache per zs_pool (in the case of zswap, I suppose it's one for
> each compression algorithm, which is usually just one - but still...).
>
> Is there any lock contention implications?
cache_alloc_handle()/cache_alloc_zspage() (and their free counterparts)
are called outside of scope of any zsmalloc locks, so the upper boundary
on the number of concurrent callers is the same - num_online_cpus().
Powered by blists - more mailing lists