linux-kernel - Re: [PATCH 0/3] mm: remove zpool

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=P=2cm7X4VMGO==xqmcFfBj4tq_YU9DqCSbyAmCioDccg@mail.gmail.com>
Date: Fri, 5 Sep 2025 14:35:12 -0700
From: Nhat Pham <nphamcs@...il.com>
To: Yosry Ahmed <yosry.ahmed@...ux.dev>
Cc: Johannes Weiner <hannes@...xchg.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	Chengming Zhou <zhouchengming@...edance.com>, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] mm: remove zpool

On Fri, Sep 5, 2025 at 12:45 PM Yosry Ahmed <yosry.ahmed@...ux.dev> wrote:
>
> On Fri, Sep 05, 2025 at 10:52:18AM -0700, Nhat Pham wrote:
> > On Fri, Aug 29, 2025 at 9:22 AM Johannes Weiner <hannes@...xchg.org> wrote:
> > >
> > > zpool is an indirection layer for zswap to switch between multiple
> > > allocator backends at runtime. Since 6.15, zsmalloc is the only
> > > allocator left in-tree, so there is no point in keeping zpool around.
> > >
> >
> > Taking a step back, even if we do have needs for multiple allocators
> > for different setups, having it runtime-selectable makes no sense.
>
> Honestly I think we should take it a step further and make the
> compressor selection only at build/boot time and completely get rid of
> supporting having multiple pools. We'd create one pool at initilization
> and that would be it.
>
> I believe this will simplify things considerably, and I doubt changing
> the compressor at runtime has a valid use case beyond experimentation.

You are completely right.

And, even if there's a setup where we benefit from multiple
compressors, the current setup is definitely not it. How are we
realistically going to use these sysfs knobs? Change to one
compressor, then quickly change it back? How is this remotely useful?

Let's remove it all. In the future, if we want to do multiple
compression tiers, or per-cgroup compression algorithm, we will need a
completely different architecture anyway.