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

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

On Wed, 2026-04-29 at 19:47 -0700, Matthew Brost wrote:
> 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.

+1 for wiring order into shrink_control, and possibly also the priority
as mentioned in an earlier email.

However for cgroups-aware shrinkers, The number of free memory in a
zone might not be an indication of fragmentation-triggered reclaim at
all, it could be the result of the cgroup hitting its memory limits.

So I think if we can solve this with a combination of GFP flags,
plumbed-through order and plumbed-through priority, that would be
ideal.

Thanks,
Thomas

> 
> Matt
> 
> > 
> > 
> > -- 
> > Cheers,
> > 
> > David