Re: [PATCH RFC] mm/zswap: reference the pool by index to shrink struct zswap_entry

[Nhat Pham]

On Mon, Jul 27, 2026 at 9:46 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> On Mon, Jul 27, 2026 at 9:35 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
> >
> > On Sun, Jul 26, 2026 at 8:18 AM Jianyue Wu <wujianyue000@xxxxxxxxx> wrote:
> > >
> > > Every stored page has a struct zswap_entry, so its size is a per-page cost
> > > that scales with how many pages zswap holds.  It currently embeds an
> > > 8-byte pool pointer.
> > >
> > > Replace the pointer with a u16 index into an allocating xarray of pools.
> > > The index is allocated with the pool and remains valid while entries hold
> > > references to that pool.
> > >
> > > On x86_64, the zswap_entry slab shrinks from 56 to 48 bytes per object,
> > > raising objs_per_slab from 73 to 85.  This saves about 2MiB of metadata
> > > per 1GiB of data held in zswap.
> >
> > TBH, that doesn't seem that major... It's like one huge page man.
> >
> > But Yosry might disagree?
>
> Well, it's free memory :)
>
> >
> > On the design aspect:
> >
> > 1. How many pools can there be? My understanding is it's bounded by
> > the number of compression algos, and most of the time the system just
> > use one, no? Maybe just add a fixed array and call it a day? :) Seems
> > like we can probably get away with, say a fixed array 16 elements.
> > That seems plenty. You can reduce the number of bits it takes to
> > describe the index to 4 (saving the spare bits for future usage), and
> > you can avoid the xarray overhead...? Just fail and warn when you have
> > reached capacity, maybe? :)
>
> Hmm yeah good point, we do reuse the pools for the same compressors. I
> don't know if crypto defines an upper limit on the number of
> compression algorithms. If we want to be really conservative we can
> use an array of 256 elements indexed by a u8. That's 1KB of memory,
> probably mostly wasted. We can also just define an artificial limit on
> the number of compressors based on what we currently have implemented
> and increase it when needed?
>
> Not sure what's an easy way to determine all crypto compression
> algorithms we have tho.

Seems like we only create new pool when we set a new compression algo right?

In a sense, it's not really about how many compression algorithm we
compile or support at runtime. It's the compression algo that we
actually set (zswap_setup() and zswap_compressor_param_set()). And
it's usually 1 (or 2 if we misconfigure the build config, lol).

I think 16 is already plenty for this purpose, but who knows :)

>
> >
> > 2. Note that the zswap pools are also organized into a list. If you're
> > adding a new data structure, maybe remove that. Or maybe the other way
> > around - can use it that linked list for your purpose?
>
> Also a good point, I think we may be able to drop the list, and I
> think that's ultimately more valuable than the memory savings. It's
> unneeded complexity.

Yeah seems unnecessarily dynamic.