linux-kernel - Re: [RFC PATCH] zsmalloc: make common caches global

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKEwX=PxJo6RijehmJMz+kK45Qr9AcQMCedO7KY_+GWzsW20tQ@mail.gmail.com>
Date: Mon, 19 Jan 2026 13:43:12 -0800
From: Nhat Pham <nphamcs@...il.com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: 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 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?

>