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

[KunWu Chan]

On Wed, Sep 23, 2026 at 6:15 PM Kairui Song <ryncsn@xxxxxxxxx> wrote:
>
> 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.

Alex, One question about the `nr_reclaimed` accounting.

`PAGE_DROPBEHIND` increments `nr_reclaimed` when the write is
submitted, while the folio may still be under writeback and is only
actually removed from the swap cache when writeback completes.

Kairui pointed out that async swap can over-reclaim because
`nr_reclaimed` does not increase while anon folios remain under
writeback. Does the early accounting for `PAGE_DROPBEHIND` address
that over-reclaim mechanism for this `MADV_PAGEOUT` path?

It might also be useful to check this with a delayed swap device, such
as the `dm-delay` case Kairui mentioned.

Thanks,
Kunwu