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

[Kairui Song]

On Wed, Sep 23, 2026 at 11:47 AM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 9/23/26 11:35, Kairui Song wrote:
> > 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:
> >>>
> >>> 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.
>
> :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.
> >
> >>>
> >>> 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.
> Ah, that hints at the real problem then? How confident are we that that's what's
> happening?

Given the fact that ZRAM/ZSWAP doesn't suffer from this, I think this
is the cause: the main difference is that ZRAM/ZSWAP frees the folios
after pageout() so nr_reclaimed is increased (reclaim loop just keeps
comparing nr_reclaimed to nr_to_reclaim), other swap devices keep the
folios under writeback, and continue reclaiming unless they hit enough
clean folios to drop.

I can't say I'm 100% sure, and it's hard to verify but I think we need
to try fixing this instead. It's not hard to construct a case where
all anon folios are put under writeback due to very slight pressure,
e.g. a dm-delay (e.g. 500ms?), 1G anon in one memcg, very slight
memorey pressure could easily put nearly all anon folios under
writeback.