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

[Lorenzo Stoakes (ARM)]

On Tue, Sep 22, 2026 at 06:37:38PM +0800, 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:
> > >>
> > >> On 9/21/26 17:24, Alexandre Ghiti wrote:
> > >>> On an asynchronous swap device MADV_PAGEOUT only marks the folio
> > >>> PG_reclaim and rotates it to the tail of the inactive list once its
> > >>> writeback completes, so the memory is not actually freed until a later
> > >>> reclaim scan removes the by then clean swap cache folio.
> > >> But we have the same behavior when just reclaiming memory ordinarily? It's added
> > >> to the swapcache and only the next scan actually frees up the memory.
> > >>
> > >> Wouldn't we memory we reclaim ... just gone, like in the sync case?
> > >
> > > 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`.
>
> 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. Neither blk-wbt, mq-deadline nor a PG_workingset
> gate recovered it. MADV_PAGEOUT alone may still be worth it, since there
> userspace has explicitly declared the range cold, but I have not measured
> that case in isolation yet."
>
> [1] https://lore.kernel.org/linux-mm/20260921151306.625134-1-alex@xxxxxxxx/
>
> Best Regards
> Barry

This patch as-is is just way way way WAY too complicated and fragile IMO.

Whatever cases you have found, they need to be fixed somewhere
fundamental. All of this feels like a hack.

If you're having to write a comment like:

/*
 * If X is Y, but not if B, and if Z is J but not if the moon's bright at
 * night, then maybe we will foo the bar, but only if the baz is blarghed,
 * ...
 */

That usually means you're doing something horribly wrong.

And this patch has multiple comments like that.

--
Cheers, Lorenzo