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

From: Alexandre Ghiti

Date: Mon Nov 02 2026 - 02:46:27 EST


Hi Nhat,

Sorry I missed your answer.

On Fri, Oct 16, 2026 at 6:19 PM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> >
> On Wed, Oct 7, 2026 at 8:39 AM 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.
>
> Would there be regression with shrinker on, when we have mixed zswap
> and disk swap backends?

Readahead won't happen if the faulting entry is in zswap but it keeps
happening when the faulting entry is on disk. But if a zswap fault
does not bring its disk neighbours, we will incur the latency of the
disk read on the first disk neighbour that faults.

It's hard to say if this would regress, it must depend on the
distribution. v2 deals with that so would you like me to resurrect it?
That would be in addition to this patch as I'm about to send to the v4
so it gets merged.


>
> >
> > 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
> >
> > 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.
> >
> > Suggested-by: Usama Arif <usama.arif@xxxxxxxxx>
> > Signed-off-by: Alexandre Ghiti <alex@xxxxxxxx>
>
> Code looks solid to me otherwise! Nice job.
>

Thanks!

Alex