Re: [PATCH v3] mm: bypass swap readahead for zswap

[Alexandre Ghiti]

Hi Barry,


On Wed, Oct 7, 2026 at 11:05 PM Barry Song <baohua@xxxxxxxxxx> wrote:
>
> >
> On Wed, Oct 7, 2026 at 11:39 PM Alexandre Ghiti <alex@xxxxxxxx> wrote:
> >
> > Commit 0bcac06f27d7 ("mm, swap: skip swapcache for swapin of synchronous
> > device") made SWP_SYNCHRONOUS_IO devices (e.g. zram) skip swap readahead.
> >
> > zswap is the same kind of in-memory, synchronous backend as zram, not a
> > swap device flagged SWP_SYNCHRONOUS_IO so it still goes through
> > swapin_readahead().
> >
> > Here are the results from bypassing readahead for zswap too: it was
> > measured with a kernel build (make -j16) in a memcg, zswap=zstd, shrinker
> > off, on Sapphire Rapids and 3 iterations.
> >
> >   768M memcg (sustained swap thrash):
> >     metric                 mm-new    + bypass    delta
> >     build time (s)          405.0       341.7    -15.6%
> >     zswap-in (GB)            79.5        53.0     -33%
> >     zswap-out (GB)          144.8       115.6     -20%
> >     swap readahead (pages)  6.79M       0.45M     -93%
> >     swap_ra hit (%)          72.1        89.9     +18pp
> >
> >   1G memcg (light pressure, build not memory-bound):
> >     metric                 mm-new    + bypass    delta
> >     build time (s)          177.7       176.0    ~same (no regression)
> >     zswap-in (GB)            10.2         7.5     -26%
> >     zswap-out (GB)           27.7        25.1      -9%
> >     swap readahead (pages)  1.07M       0.08M     -93%
> >     swap_ra hit (%)          68.6        87.2     +19pp
>
> Hi Alexandre,
>
> I assume your configuration is as below?
>
> / # cat /proc/sys/vm/page-cluster
> 3
> / # cat /sys/kernel/mm/swap/vma_ra_enabled
> true

Yes

>
> I am curious whether setting `/proc/sys/vm/page-cluster` to either 0
> or 1 would result in the same performance gain on a zswap-enabled
> system?

I'll test and report back here.

>
> >
> > Similar gains were observed on an AMD EPYC 7D13 host.
> >
> > The gain is from no longer prefetching pages that are pointless for an
> > in-memory backend: readahead inflates anon residency and thrashes the
> > page cache (file pages get evicted and re-read), lengthens each fault by
> > synchronously (de)compressing a cluster of neighbours, and adds
> > compression traffic when those extra pages are reclaimed.
> >
> > Bypassing swap readahead for zswap therefore makes sense.
> >
>
> The change makes sense to me. I am just curious whether setting those
> configurations would result in the same performance gain.
>
> Maybe you can mention the `page-cluster` configuration in the changelog
> as well.

Sure, I'll do that.

>
> > Suggested-by: Usama Arif <usama.arif@xxxxxxxxx>
> > Signed-off-by: Alexandre Ghiti <alex@xxxxxxxx>
> > ---
>
> Reviewed-by: Barry Song <baohua@xxxxxxxxxx>
>
> This is RC6 now. You probably need to respin it after the new RC1.
>

Thanks Barry!

Alex