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

[Matthew Brost <matthew.brost@intel.com>]

On Thu, Apr 23, 2026 at 12:08:36PM -0700, Matthew Brost wrote:
> On Thu, Apr 23, 2026 at 01:27:11PM +0200, Thomas Hellström wrote:
> > On Thu, 2026-04-23 at 12:27 +0200, David Hildenbrand (Arm) wrote:
> > > On 4/23/26 07:56, Matthew Brost wrote:
> > > > Introduce zone_appears_fragmented() as a lightweight helper to
> > > > allow
> > > > subsystems to make coarse decisions about reclaim behavior in the
> > > > presence of likely fragmentation.
> > > > 
> > > > The helper implements a simple heuristic: if the number of free
> > > > pages
> > > > in a zone exceeds twice the high watermark, the zone is considered
> > > > to
> > > > have ample free memory and allocation failures are more likely due
> > > > to
> > > > fragmentation than overall memory pressure.
> > > > 
> > > > This is intentionally imprecise and is not meant to replace the
> > > > core
> > > > MM compaction or fragmentation accounting logic. Instead, it
> > > > provides
> > > > a cheap signal for callers (e.g., shrinkers) that wish to avoid
> > > > overly aggressive reclaim when sufficient free memory exists but
> > > > high-order allocations may still fail.
> > > > 
> > > > No functional changes; this is a preparatory helper for future
> > > > users.
> > > > 
> > > > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > Cc: David Hildenbrand <david@kernel.org>
> > > > Cc: Lorenzo Stoakes <ljs@kernel.org>
> > > > Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>
> > > > Cc: Vlastimil Babka <vbabka@kernel.org>
> > > > Cc: Mike Rapoport <rppt@kernel.org>
> > > > Cc: Suren Baghdasaryan <surenb@google.com>
> > > > Cc: Michal Hocko <mhocko@suse.com>
> > > > Cc: linux-mm@kvack.org
> > > > Cc: linux-kernel@vger.kernel.org
> > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > > > ---
> > > >  include/linux/vmstat.h | 13 +++++++++++++
> > > >  1 file changed, 13 insertions(+)
> > > > 
> > > > diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
> > > > index 3c9c266cf782..568d9f4f1a1f 100644
> > > > --- a/include/linux/vmstat.h
> > > > +++ b/include/linux/vmstat.h
> > > > @@ -483,6 +483,19 @@ static inline const char *zone_stat_name(enum
> > > > zone_stat_item item)
> > > >  	return vmstat_text[item];
> > > >  }
> > > >  
> > > > +static inline bool zone_appears_fragmented(struct zone *zone)
> > > > +{
> > > 
> > > "zone_likely_fragmented" or "zone_maybe_fragmented" might be clearer,
> > > depending
> > > on the actual semantics.
> > > 
> > > > +	/*
> > > > +	 * Simple heuristic: if the number of free pages is more
> > > > than twice the
> > > > +	 * high watermark, this strongly suggests that the zone is
> > > > heavily
> > > > +	 * fragmented when called from a shrinker.
> > > > +	 */
> > > 
> > > I'll cc some more people. But the "when called from a shrinker" bit
> > > is
> > > concerning. Are there additional semantics that should be expressed
> > > in the
> > > function name, for example?
> > > 
> > > Something that implies that this function only gives you a reasonable
> > > answer in
> > > a certain context.
> > 
> > I think that test would not be relevant for cgroup-aware shrinking.
> > 
> > What about trying to pass something in the struct shrink_control? Like
> > if we pass the struct scan_control's order field also in struct
> 
> 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/
> 
> > shrink_control, really expensive shrinkers could duck reclaim attempts
> > from higher-order allocations that may fail anyway:
> > 
> >       if (sc->order > PAGE_ALLOC_COSTLY_ORDER &&
> >            (sc->gfp_mask & (__GFP_NORETRY | __GFP_RETRY_MAYFAIL)) &&
> >            !(sc->gfp_mask & __GFP_NOFAIL))

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

 1182 [  394.049058] xe_shrinker_scan: no skip order=9, gfp=0x0000000000000cc0
 1183 [  394.049061] CPU: 2 UID: 0 PID: 110 Comm: kswapd0 Not tainted 7.0.0-xe+ #355 PREEMPT(full)
 1184 [  394.049062] Hardware name: Intel Corporation Panther Lake Client Platform/PTL-UH LP5 T3 RVP1, BIOS PTLPFWI1.R00.3332.D05.2509011438 09/01/2025
 1185 [  394.049063] Call Trace:
 1186 [  394.049065]  <TASK>
 1187 [  394.049066]  dump_stack_lvl+0x55/0x70
 1188 [  394.049073]  xe_shrinker_scan+0x274/0x280 [xe]
 1189 [  394.049181]  do_shrink_slab+0x132/0x360
 1190 [  394.049184]  shrink_slab+0xf0/0x3e0
 1191 [  394.049186]  shrink_node+0x2bd/0x800
 1192 [  394.049188]  balance_pgdat+0x323/0x760
 1193 [  394.049189]  kswapd+0x1c3/0x340
 1194 [  394.049190]  ? __pfx_autoremove_wake_function+0x10/0x10
 1195 [  394.049193]  ? __pfx_kswapd+0x10/0x10
 1196 [  394.049194]  kthread+0xdf/0x120
 1197 [  394.049196]  ? __pfx_kthread+0x10/0x10
 1198 [  394.049197]  ret_from_fork+0x1d0/0x220
 1199 [  394.049200]  ? __pfx_kthread+0x10/0x10
 1200 [  394.049200]  ret_from_fork_asm+0x1a/0x30
 1201 [  394.049202]  </TASK>

Will look into if this is fixable, but again any core MM guidance would
helpful.

Matt

> >            return SHRINK_STOP;
> > 
> > Possibly exposed as an inline helper in the shrinker interface?
> > 
> > /Thomas
> > 
> > 
> > 
> >