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

[Alexandre Ghiti]

Hi KunWu,

On Wed, Sep 23, 2026 at 6:22 PM KunWu Chan <kunwu.chan@xxxxxxxxx> wrote:
>
> >
> 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?

Unvoluntarily yes :)

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

Yes, I'm setting up a new experiment to check everything mentioned in
this thread.

Thanks,

Alex

>
> Thanks,
> Kunwu
>