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

[David Hildenbrand (Arm)]

On 9/22/26 22:55, Barry Song wrote:
> On Tue, Sep 22, 2026 at 7:26 PM David Hildenbrand (Arm)
> <david@xxxxxxxxxx> wrote:
>>
>> On 9/22/26 12:37, Barry Song wrote:
>>> On Tue, Sep 22, 2026 at 6:20 PM David Hildenbrand (Arm)
>>> <david@xxxxxxxxxx> wrote:
>>>
>>> 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`.
>>
>> I really hate to add special sauce for MADV_PAGEOUT. Also, I don't quite like
>> that we do something fundamentally different for sync vs. async.
>>
>> I assume, though, that async writeback that is very fast might just find the
>> !folio_test_writeback() scenario just like the sync case. ... or if we
>> reschedule after pageout()?
>>
>> I am wondering: if we can show that letting async swapped out pages stay in
>> memory a bit longer improves performance, aren't we swapping out the wrong pages
>> in the first place, and not swapping them out would help the sync case as well?
> 
> 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?

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?

> 
> 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.

> 
>>
>>>
>>> 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.
>>
>> Thanks, does this represent a workload pattern we care about?
> 
> 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 :)

> 
> Kairui also mentioned to me that he once tried releasing memory
> immediately after folios were written back to HDD, and saw some
> serious performance regressions as well. Maybe Kairui can also share
> some thoughts on this.

Would be good to find the root cause for this: why are we swapping out these
pages that are immediately needed again such that it affects performance that
drastically.

-- 
Cheers,

David