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

[Matthew Brost]

On Fri, Apr 24, 2026 at 09:26:18AM +0200, David Hildenbrand (Arm) wrote:
> 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)
> 

Yes.

My current thinking is wire the order into shrink_control as that is
quite straight forward + only call this helper + short circuit shrinker
on higher orders.

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

Yes, this seems non-trivial. I was also on a call with Google today
discussing what Android (client Linux) would like from shrinking, and my
initial feeling is that we will need to do some surgery to the shrinker
core and GPU shrinkers to make all of this work well over the next year
or so.

So again, I think starting with wiring order into shrink_control and
this helper is a good place to start, as it fixes an immediate issue.

Let me know if that seems like a reasonable direction.

Matt

> 
> 
> -- 
> Cheers,
> 
> David