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

[Kairui Song]

On Wed, Sep 23, 2026 at 10:46 AM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 9/22/26 22:55, Barry Song wrote:
> > 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:
> >>>
> >>> 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?

Hi All,

>
> Right. But these would happen in both the SYNC and the ASYNC case. Which seems
> to indicate that making the SYNC case behave like the ASYNC case (keep in
> swapcache before evicting) could actually improve performance?
>
> Or is the SYNC case in general so fast that it is not a problem and the
> swapcache is just not a good use?

I think the problem is not LRU being inaccurate, but ASYNC case could
overshoot the anon reclaim very easily. File folios can be simply
dropped, and increase nr_reclaimed, but anon writeback (swap) can't be
done durig the reclaim iteration so nr_reclaimed never increase during
the scan iteration. So the scan tries hard to scan and reclaim more
anon folios, more than it really needed.

I think the real fix is some kind of different watermark, throttling,
or a different counter to limit the scan of async swap. I mentioned
this at LSFMM this year but I guess I presented too much at the same
time so few people remembered it :D.

>
> >
> > 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?
>
> Why is that specific for HDD? It's the exact same app behavior independent of
> the underlying swap technology.

If you have a shared folio, you must use swap cache, and even for
single used folios swap cache is the way to do synchronization,
regardless of the device.

> >>> 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.
>
> Right. And see if we can identify why we are swapping out the wrong things :)

I think we are not? It's about over-reclaim. In the worst case we
might put every anon folio under writeback, while no folio is
reclaimed, if the device is super slow. And if we drop it on writeback
completion, we could drop the entire anonymous portion of an
application. Of course, the performance will be horrible.

We don't have such problem for ZRAM because ZRAM just releases the
folio during the reclaim iteration so the nr_reclaim counter gets
updated properly, and the iteration ends properly.

For async swap device, writeback is async, so the reclaim loop just go
on without updating nr_reclaimed (they are not reclaimed, still under
writeback). The reclaim iteration only ends after it reclaimed enough
clean file folios or previously written-back clean swap cache. MM
reclaim is expecting to see clean swap cache after writeback is done
and rotate them back to LRU tail so next reclaim can catch them.

BTW we could hit OOM even if swap is enabled due to a similar problem.
Anon reclaim can't really free anon folios, so it always relies on
having enough clean cache (page cache or swap cache) to drop to avoid
OOM. It just keeps pushing anon pages into writeback when under
pressure (expecting that this helps the next reclaim cycle.

This is ugly, I also wanted to figure out a proper fix but got busy
with other stuff :D