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

[Kairui Song]

On Mon, Oct 12, 2026 at 3:57 PM Barry Song <baohua@xxxxxxxxxx> wrote:
>
> On Thu, Oct 8, 2026 at 5:37 AM Yosry Ahmed <yosry@xxxxxxxxxx> 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.
> > >
> > >   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.
> >
> > No objection here, I am just thinking about Kairui's LPC presentation
> > about how compressed swap can (in theory at least) still benefit from
> > readahead: https://lpc.events/event/20/contributions/2421/attachments/2116/4689/Better%20Anon%20(Swap)%20Readahead%20(2).pdf.
> >
> > Seems like a big portion of the fault cost is still outside of
> > decompression and can benefit from readahead, but that isn't the case
> > today. I assume any future improvements to readahead and re-enabling
> > for zram would also cover zswap?
> >
>
> In that case, if we can develop an accurate readahead algorithm with a
> high hit rate for readahead folios, we will probably also need to map
> them at the same time, as proposed in [1]. For example, if we readahead
> 4 folios, we should map them all together in `do_swap_page()`.
> Otherwise, the cost of future minor faults can still be comparable to
> the decompression cost. Readahead alone would therefore increase the
> total work, which can be quite significant for synchronous I/O.
>
> [1] https://lore.kernel.org/linux-mm/CAGsJ_4xM=WnFO-OuwVude-DQ_UkaCi_zF_bXBP9Li5+ZPNy0VQ@xxxxxxxxxxxxxx/

That's a really nice POC! We should do that IMO, maybe with better
support for (m)THP readahead too.

We first need a better readahead policy though, or else unmapping
these folios might cost even more.

For the readahead part I'm thinking about evaluating using shadow as a
stronger hint for readahead after MGLRU-FG which helps distribute the
folios based on frequencey more evenly among gens, also with a more
proactive aging (async aging, or maybe lru_gen_imbalanced as Barry
once suggested somewhere) so folios in the same gen with same freq
will be much more likely to be reused. Or something similiar to file
readahead's PG_readahead based readahead. Well more
experiments are needed first though.