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

["Jose A. Perez de Azpillaga" <azpijr@gmail.com>]

On 11/5/26 12:52 PM, Vlastimil Babka (SUSE) wrote:
> 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.
> 

don't worry :)

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

makes sense to me, as long as kswapd reclaims something. if it doesn't
it goes hopeless after MAX_RECLAIM_RETRIES runs and stays that way until
the node is balanced, so that's only ~16 unreserves per zone.

-- 
cheers,
jose a. p-a