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.

Based on mm-everything-2025-08-29-00-23.

 Documentation/admin-guide/mm/zswap.rst             |  33 +--
 Documentation/core-api/mm-api.rst                  |   1 -
 Documentation/driver-api/crypto/iaa/iaa-crypto.rst |   2 -
 MAINTAINERS                                        |   2 -
 arch/loongarch/configs/loongson3_defconfig         |   1 -
 include/linux/zpool.h                              |  86 ------
 mm/Kconfig                                         |  49 +--
 mm/Makefile                                        |   1 -
 mm/zpdesc.h                                        |  14 +-
 mm/zpool.c                                         | 328 ---------------------
 mm/zsmalloc.c                                      |  79 -----
 mm/zswap.c                                         | 202 ++++---------
 tools/testing/selftests/zram/README                |   1 -
 13 files changed, 84 insertions(+), 715 deletions(-)

On Fri, Aug 29, 2025 at 9:22 AM Johannes Weiner <hannes@cmpxchg.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.

If you just need one particular allocator per-set up, then it's better
select it at build/boot time. And we have ways to do it, without
adding 700+ LoCs boilerplate.

So:

Acked-by: Nhat Pham <nphamcs@gmail.com>

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@cmpxchg.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.

WDYT?

On Fri, Sep 5, 2025 at 12:45 PM Yosry Ahmed <yosry.ahmed@linux.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@cmpxchg.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.

On Fri, Sep 05, 2025 at 02:35:12PM -0700, Nhat Pham wrote:
> On Fri, Sep 5, 2025 at 12:45 PM Yosry Ahmed <yosry.ahmed@linux.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@cmpxchg.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.

+1 Completely agreed, it's not worth all this fragile code in zswap.c.

I'll send follow-up patches.

On Tue, Sep 09, 2025 at 04:03:26PM +0100, Johannes Weiner wrote:
> On Fri, Sep 05, 2025 at 02:35:12PM -0700, Nhat Pham wrote:
> > On Fri, Sep 5, 2025 at 12:45 PM Yosry Ahmed <yosry.ahmed@linux.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@cmpxchg.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.
> 
> +1 Completely agreed, it's not worth all this fragile code in zswap.c.
> 
> I'll send follow-up patches.

Awesome, thanks!

> With zswap using zsmalloc directly, there are no more in-tree users of
> this code. Remove it.
> 
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>

Per the previous discussions, this gets a *NACK* from my side. There is
hardly anything _technical_ preventing new in-tree users of zpool API.
zpool API is neutral and well-defined, I don’t see *any* good reason for
it to be phased out.

BTW, remarkable is that you didn't bother to CC: me to this patch.

Anyway,

Nacked-by: Vitaly Wool <vitaly.wool@konsulko.se>