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

[Barry Song]

On Mon, Oct 12, 2026 at 10:21 PM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Mon, Oct 12, 2026 at 1:01 AM Barry Song <baohua@xxxxxxxxxx> wrote:
> >
> >
> > Thanks! This seems to be a strong indication that setting
> > `page-cluster = 0` can also resolve your problem, even without your
> > patch. :-)
>
> If every tenants use zswap, yes. But we have tenants with different
> kinds of swap backend in the same host (some using compressed
> synchronous swap backend, some async IO swap backend).
>
> >
> > But I'm still glad to see your auto-tuning patch!
>
> I think we need some smarter readahead work, for sure. I'm just not
> quite sure what it'd look like in the end, though.
>
> Doing synchronous readahead work in page fault feels wrong. I chatted
> very briefly with Kairui about this. Kairui is trying to come up with
> smarter readahead heuristics, but I don't know - even if it's 100%
> hitrate, we're concentrating work of multiple pagefaults into a single
> pagefault. That sounds off to me?
>
> Crazy idea time - what if instead of skipping readahead for
> zswap/zram, we offload it to asynchronous worker (only synchronously
> loading the target page)? That'll cancel out the latency issue at
> least...?

I am quite sure I tried this 3 or 4 months ago, and the
performance was very poor. The problem is that async wake-up
latency is highly unpredictable. For example, do_swap_page()
can complete all the mapping and decompression work in less
than 10 us. However, if we queue the work to an async thread,
its wake-up latency alone could be much longer than 10 us.

Based on my results, async zram readahead only works if we have
hardware queues rather than relying on async threads.

Best Regards
Barry