Re: [PATCH] mm, vmscan: make kswapd unreserve highatomic pageblocks

[Vlastimil Babka (SUSE)]

On 11/5/26 12:43, Jose A. Perez de Azpillaga wrote:
> On 11/5/26 9:02 AM, Vlastimil Babka (SUSE) wrote:
>> On 11/4/26 22:56, Jose A. Perez de Azpillaga wrote:
>>> On 11/4/26 7:38 PM, Vlastimil Babka (SUSE) wrote:
>>>> Hook this highatomic unreserve to the moment we are increasing kswapd
>>>> reclaim priority, as that is when kswapd is struggling to make progress
>>>> and it should roughly match the case of direct reclaim failure.
>>>>
>>>
>>> isn't raise_priority true after almost every pass at DEF_PRIORITY, stuck
>>> or not?
>> 
>> Can you elaborate why? At least at first glance, kswapd_shrink_node() should
>> return true if it scans the requested amount of pages. So I would assume
>> that although balance_pgdat() will do multiple iterations to reach high
>> watermarks (because every round of kswapd_shrink_node() will limit itself to
>> SWAP_CLUSTER_MAX per zone for sc->nr_to_reclaim) this should not be raising
>> priority if the rounds are successful?
>> 
> 
> 
> it's max(high_wmark_pages(zone), SWAP_CLUSTER_MAX) per zone, so the sum
> of the high watermarks. by default that's at least managed/500, while

Ah thanks, as usual I got the min/max logic wrong, hehe.

> DEF_PRIORITY scans lru >> 12, so it can't return true above priority 8
> even when every round is successful. and sc.priority-- runs before
> pgdat_balanced() is rechecked, so a wakeup that balances the node in one
> pass still unreserves a pageblock per zone.

Yeah in that case it would probably be safer to perform the unreserve only
after reaching the highest (lowest numerically) priority and still failing?
I think it should still be enough to recover from the pathological scenario,
which should be rare (but not impossible) in the first place.