Re: [PATCH v2 1/5] mm: Introduce zone_appears_fragmented()

[David Hildenbrand (Arm)]

On 4/24/26 09:05, Thomas Hellström wrote:
> On Thu, 2026-04-23 at 15:21 -0700, Matthew Brost wrote:
>> On Thu, Apr 23, 2026 at 12:08:36PM -0700, Matthew Brost wrote:
>>>
>>> If the order were included in shrink_control, there is about a 95%
>>> certain that this change would allow TTM / Xe to break the
>>> problematic
>>> kswapd feedback loop. This may also better express the intent of
>>> the
>>> problem we are trying to fix here.
>>>
>>> For reference, the cover letter [1] details the problem.
>>>
>>> Any guidance from the core MM folks would be appreciated—would
>>> adding
>>> the order to shrink_control be an acceptable solution?
>>>
>>> Matt
>>>
>>> [1] https://patchwork.freedesktop.org/series/165330/
>>>
>>
>> It doesn't look like __GFP_NORETRY, __GFP_RETRY_MAYFAIL, __GFP_NOFAIL
>> make it to the sc->gfp_mask flags from the caller and get into kswapd
>> loop...
> 
> Perhaps that's because they mostly (only?) make sense from direct
> reclaim? Looks like the trace is from kswapd.

kswap obtains the desired order through pgdat->kswapd_order, as a hint from
allocation code (wakeup_kswapd). The order can be easily merged (just use the max)

We do have the gfp_flags there, but merging them from different wakeups is a bit
more tricky (and when to reset?).

Assume we have one urgent request for order-0 and one non-urgent
(noretry,nofail, ...) request for order-9, we'd have to figure out a way how to
represent that. Gets more complicated for more orders.

Of course, we could have some kind of array, and try to store some "priority"
per order. But I assume plumbing that into the rest of kswapd might not be that
easy.


-- 
Cheers,

David