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

[David Hildenbrand (Arm)]

On 9/22/26 12:37, 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:
>>>
>>> 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`.

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?

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

-- 
Cheers,

David