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

[Barry Song]

On Fri, Jun 26, 2026 at 12:39 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Wed, Jun 24, 2026 at 12:24 PM Barry Song <baohua@xxxxxxxxxx> wrote:
> >
> > Basically, I have been seeing the same issue recently. If the
> > readahead swap entries are also in zswap, we end up doing the
> > decompression during one page fault, but then need another page fault
> > to fetch the page from the swap cache and install the mapping. In that
> > case, readahead may not be beneficial.
>
> You're playing with zswap? Nice :)

Hi Nhat,

Sorry for the late reply. I've been quite busy recently.
I used to work on zswap when I was in the server industry. These days, I
still play with it from time to time, mostly for fun.

>
> It does feel like we're leaving some obvious wins on the table with
> zswap here, so any ideas are much appreciated :)

For my part, I'm not against either zram or zswap. They both play
important roles in their respective domains. :-)

>
> >
> > On the other hand, if the readahead swap entries are not in zswap, the
> > situation is different.
> >
> > For example, suppose we fault on the swap entry for address 1 MB and
> > readahead brings in the entry for 1 MB + 4 KB. If both entries are in
> > zswap, readahead does not seem like a good trade-off. However, if the
> > 1 MB + 4 KB entry is not in zswap and would otherwise require storage
> > I/O, then readahead can be beneficial.
>
> Yeah I can see the edge case you and Yosry brought up here. As we move
> towards supporting multiple swap backends in the same system, that can
> certainly happen. I'm hoping that locality will bail us out - pages
> close together in virtual address space hopefully have similar
> lifetime, access temperature, compressibility, and will go to the same
> swap backend, etc. - but who knows :)
>
> What if we still follow the readahead logic, but at each slot in the
> readahead window, we check if the entry is owned by zswap or is of a
> sync-io devices, in which case we skip the readahead...?

That sounds fine to me. I'm just not sure how complex the code would
be. Would the readahead path need to check whether folios are in zswap
or not? That sounds like a pain.

>
> That way, we will still submit the IO work, but spare the ones that
> require synchronous decompression work, which might affect latency...?

Yes, but it seems like it could get quite complex. So I'm fine with
either the current approach in this patch, or simply disabling
readahead once we're sure we're using zswap, without even checking
whether the current swap-in is coming from zswap.

>
> >
> > So I implemented a rather ugly fault_around-like mechanism in
> > do_swap_page(). At least with page-cluster == 1, I am seeing a
> > performance improvement, as the readahead folios can be mapped
> > directly and do not require a second page fault.
>
> Hmm so what your proposal buys us is, if we're already doing readahead
> (synchronously), might as well install the pages in the window into
> the page tables? :)

Yes, because it avoids another page fault. Handling two pages in a
single page fault is faster than handling two separate page faults,
each faulting in one page. Since we've already read the data out
synchronously, we don't want to fault on it again. The downside is
that it increases the complexity of do_swap_page().

I'm not even trying to sell my approach—I did it just for fun.
do_swap_page() is already quite complex, and my fault-around
implementation only makes it more complicated. So I don't really want
to push for it to be merged upstream. I think it will become much more
attractive once we have hardware-assisted decompression in
do_swap_page(), where we no longer spend CPU cycles on
decompression.

>
> Could you explain to me how does this improve performance? If the
> pages are needed, we are transferring some work from future page
> faults to the current page fault. If the pages are not needed, then we
> are just wasting cycles right?

Yep. I'm only seeing improvements with page-cluster=1, which uses a
small readahead window. For page-cluster > 2, I'm seeing performance
regressions on workloads such as kernel builds. On the other hand, a
larger page-cluster provides a bigger benefit for sequential swap-ins.
So it's not a universal win.

>
> >
> > It is admittedly quite ugly and is only meant as a proof of concept :-)
>
> Dw, arguably it's easier to reason about with everything open-coded ;)

Thanks for your kind words.

Best Regards
Barry