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

[Alexandre Ghiti]

Hi Barry,

On Fri, Oct 9, 2026 at 8:22 AM Alexandre Ghiti <alexghiti@xxxxxxxx> wrote:
>
> 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.

So I ran the same workload (kbuild -j16, 768M memcg, zswap only, n=3 per arm):

    768M memcg (sustained swap thrash):
      metric                                        mm-new
page-cluster=1    page-cluster=0    + bypass
      build time (s)                               530.0      462.0
-12.8%      452.3  -14.7%    452.7  -14.6%
      zswap-in (GB)                               95.7        66.7
-30%         64.2    -33%     64.4    -33%
      zswap-out (GB)                           169.3      138.3
-18%       135.2    -20%    135.6    -20%
      swap readahead (pages)            8.37M     1.93M    -77%
  0      -100%    0.53M    -94%
      swap_ra hit (%)                            73.6        86.5
+13pp          -          -          90.7   +17pp

Exact same results with page-cluster to 0, so I'll add that to the
changelog as you suggested.

Thanks again for the review,

Alex

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