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

[Barry Song]

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