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

[Jianyue Wu]

On Tue, Jul 28, 2026 at 11:34 PM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
> > Throughput in MB/s:
> >  alg      | acomp store | zcomp store | acomp load | zcomp load
> > ----------+-------------+-------------+------------+-----------
> >  lzo      |        1140 |        1710 |       1070 |       1070
> >  lzo-rle  |        1490 |        1320 |       2030 |       2070
> >  lz4      |        1520 |        1600 |       1710 |       1870
> >  lz4hc    |         640 |         680 |       1770 |       1850
> >  zstd     |         740 |        1190 |        980 |       1720
> >  deflate  |         180 |         180 |        665 |        660
> > But that's another topic.
>
> What the hell. Do you know why that's the case? That's almost double
> the the throughput with zcomp???
Not sure, assume mostly comes from crypto-sg re-init the cctx/dctx
on every request (zstd_init_cctx()/zstd_init_dctx()), while zcomp's zstd
init the contexts once per CPU stream and reuses them on the hot
path. Crypto-nondma looks can be faster, but not checked yet.
2nd difference might be: crypto/zstd sizes the workspace
for a 256KiB window (streaming-oriented), while zcomp sizes it for
PAGE_SIZE. zswap itself is single-shot per page, so PAGE_SIZE is enough
there, not sure if we can optimize it.
That is separate from this shrink series though.

> Let's go with that. We can be defensive and just block users when they
> try to add the 17th zswap pool.
>
Ack, will use a fixed array of 16 and fail/warn on the 17th.

> Yeah you can leave that for now :)
Ack, will leave it.

Best regards,
Jianyue