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

[David Hildenbrand (Arm)]

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?

-- 
Cheers,

David