Re: [PATCH v2 1/3] mm: swap: overlap synchronous readahead decompression with disk I/O

[Alexandre Ghiti]

Hi Nhat,

On Tue, Sep 22, 2026 at 7:07 PM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> >
> On Wed, Jul 22, 2026 at 9:59 AM Alexandre Ghiti <alex@xxxxxxxx> wrote:
> >
> > Swap readahead reads the whole window sequentially: the device I/Os are
> > accumulated along the way while the synchronous, zswap-resident entries
> > are decompressed inline. The I/O is only triggered afterwards, at
> > blk_finish_plug(), so the synchronous zswap decompression is pure added
> > latency in front of the read the fault is about to wait on.
> >
> > Trigger the I/O before decompressing the synchronous entries: split the
> > window walk into two passes. Pass 1 issues the async device reads and
> > defers the synchronous neighbours; pass 2 reads the deferred entries
> > while pass 1's I/O is in flight, overlapping the CPU work with the disk
> > reads instead of serialising it in front of them.
> >
> > swap_cluster_readahead() walks a contiguous offset range, which is cheap.
> > swap_vma_readahead() instead walks the page tables so we cache the
> > entries we encounter in the first pass to reuse directly in the second
> > pass.
>
> Hmmm does not seem like you're taking advantage of the device-level
> contiguity of swap_cluster_readahead() either way? You're calling
> swap_entry_synchronous() (i.e zswap_is_present(entry, 1)) one entry
> (i.e one tree walk) at a time.
>
> If you're not taking advantage of contiguity, just share the logic haha.

I cannot stash the zswap entries in an array for the cluster readahead
path since the window is not capped like it is for the vma readahead.

So I'll use the contiguity to avoid the zswap tree lookup on each entry, thanks.

>
> >
> > Results [vm-scalability mixed zswap+disk swap-in, 256M zswap cap (~73%
> > disk), Sapphire Rapids, zswap=zstd, shrinker off, n=3]:
>
> Hmm how do you have disk swapin with shrinker off?

The test workload I used filled the zswap pool so new folios were
written to disk.

>
> >
> >   metric                  mm-new    +patch    delta
> >   swap-in tput (KB/s)    119247    131261    +10.1%
> >   swap-in wall (s)          106       100     -5.7%
> >   swap readahead (pages)   1.56M      1.55M    ~same
> >   zswap-in (MB)            1895       1872     ~same
> >   disk swap-in (MB)        5207       5190     ~same
> >   major faults            260148     260212    ~same
>
> Obviously this would help zswap, but what if the backend is disk swap,
> and all of this is just pure overhead? How would the numbers look?

You're right, I assumed the overhead would be negligible but I haven't
measured it, I'll come back with numbers (I'll test with the
contiguity optimization you mentioned; the overhead should be even
less visible).

Thanks for your review Nhat!

Alex

>
> >
> > Signed-off-by: Alexandre Ghiti <alex@xxxxxxxx
>