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

[Nhat Pham]

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.

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

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

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