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

[Yosry Ahmed]

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.

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