Re: [PATCH] mm: madvise: drop MADV_PAGEOUT folios at swap writeback completion

[Barry Song]

On Tue, Sep 22, 2026 at 7:26 PM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 9/22/26 12:37, Barry Song wrote:
> > On Tue, Sep 22, 2026 at 6:20 PM David Hildenbrand (Arm)
> > <david@xxxxxxxxxx> wrote:
> >>
> >> On 9/21/26 23:56, Barry Song wrote:
> >>> On Mon, Sep 21, 2026 at 11:37 PM David Hildenbrand (Arm)
> >>> <david@xxxxxxxxxx> wrote:
> >>>
> >>> For synchronous I/O, such as zswap and zram, the memory is released
> >>> immediately after sync I/O is done.
> >>>
> >>> For asynchronous I/O, such as NVMe, the swapcache is currently
> >>> expected to be rotated back to the tail of the LRU and wait for
> >>> another scan. Alexandre once mentioned that when he tried handling
> >>> async I/O the same way as sync I/O—releasing the memory once the I/O
> >>> completed—he saw some regression. So, delaying the release until a
> >>> later scan may allow swapcache hits before the folios are eventually
> >>> reclaimed.
> >>
> >> "may", do we have any evidence that this actually is relevant in practice?
> >>
> >> We asked to reclaim memory. We wrote the memory out to disk. We unmapped it from
> >> the page tables. We made the workload the could, access the page immediately
> >> again suffer already.
> >>
> >> We should just evict them as soon as possible to free up memory.
> >
> > I suggested this to Alexandre, and he found that it could regress some
> > workloads [1]. That is why Alexandre is only making the folios
> > immediately reclaimable for `MADV_PAGEOUT`.
>
> I really hate to add special sauce for MADV_PAGEOUT. Also, I don't quite like
> that we do something fundamentally different for sync vs. async.
>
> I assume, though, that async writeback that is very fast might just find the
> !folio_test_writeback() scenario just like the sync case. ... or if we
> reschedule after pageout()?
>
> I am wondering: if we can show that letting async swapped out pages stay in
> memory a bit longer improves performance, aren't we swapping out the wrong pages
> in the first place, and not swapping them out would help the sync case as well?

I guess that's because the LRU is not always accurate. There are cases
where our prediction of future access patterns may be wrong, resulting
in refaults?

Even on Android, which uses zram with very fast synchronous swap-out,
I can still hit the swapcache from time to time. So perhaps with a
slower device, such as an HDD, keeping the swapcache around for longer
could allow applications to hit it more often?

>
> >
> > See Alexandre's description:
> >
> > "Future work
> > -----------
> > Barry suggested extending this to MADV_PAGEOUT and general reclaim. I
> > prototyped dropbehind for all reclaimed swap folios and it regressed
> > sysbench OLTP throughput by ~15% on NVMe swap: dropping the swap cache
> > immediately turns cheap in-cache refaults into disk reads and collapses
> > swap readahead clustering.
>
> Thanks, does this represent a workload pattern we care about?

I don't know. Maybe Alexandre can share more details about this
benchmark. I'm also a little surprised by the 15% regression in
Sysbench OLTP. My initial feeling was the same as yours: we should
release the memory immediately after writeback completes, for both
synchronous and asynchronous I/O.

Kairui also mentioned to me that he once tried releasing memory
immediately after folios were written back to HDD, and saw some
serious performance regressions as well. Maybe Kairui can also share
some thoughts on this.

Best Regards
Barry