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

[Yosry Ahmed]

On Mon, Jul 27, 2026 at 9:56 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> 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 :)

Technically, you can switch compressors at runtime. Not sure if anyone
actually does this, but it is supported today, and ideally we wouldn't
break it without good reason.