Re: [PATCH v4 2/6] mm: Introduce zone_maybe_fragmented_in_shrinker()

[Santa, Carlos]

On Thu, 2026-04-30 at 12:18 -0700, Matthew Brost wrote:
> Introduce zone_maybe_fragmented_in_shrinker() 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@xxxxxxxxxxxxxxx>
> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> Cc: David Hildenbrand <david@xxxxxxxxxx>
> Cc: Lorenzo Stoakes <ljs@xxxxxxxxxx>
> Cc: "Liam R. Howlett" <Liam.Howlett@xxxxxxxxxx>
> Cc: Vlastimil Babka <vbabka@xxxxxxxxxx>
> Cc: Mike Rapoport <rppt@xxxxxxxxxx>
> Cc: Suren Baghdasaryan <surenb@xxxxxxxxxx>
> Cc: Michal Hocko <mhocko@xxxxxxxx>
> Cc: linux-mm@xxxxxxxxx
> Cc: linux-kernel@xxxxxxxxxxxxxxx
> Signed-off-by: Matthew Brost <matthew.brost@xxxxxxxxx>
> 
> ---
> 
> v3: s/zone_appear_fragmented/zone_maybe_fragmented_in_shrinker (David
>     Hildenbrand)
> ---
>  include/linux/vmstat.h | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
> index 3c9c266cf782..1ad48f70c9d9 100644
> --- a/include/linux/vmstat.h
> +++ b/include/linux/vmstat.h
> @@ -483,6 +483,18 @@ static inline const char *zone_stat_name(enum
> zone_stat_item item)
>  	return vmstat_text[item];
>  }
>  

on the below heuristic, I was thinking of the following case: a large
memory system (say 16G, 32G), heavily fragmented (for whatever reason)
but constraint by the IOMMU requiring large pages due to hw alignment,
if I am not mistaken the below check will cause the shrinker to bail
out too 'early' since the there's plenty of available memory but none
of that is contiguous, then end result should be giving back small
pages which should reduce performance, right?

below are some made up numbers:


Metric          | 8GB               | 16GB
----------------|-------------------|-------------------
High Wmark      | ~45MB (11k pgs)   | ~90MB (23k pgs)
Bail Gate (2x)  | ~90MB (22k pgs)   | ~180MB (46k pgs)
Free RAM        | 120MB             | 7100MB (7.1GB)
Shrinker        | RUNS (Free<Gate)  | BAILS (Free>Gate)
Outcome         | Merges 2MB blocks | 4KB pages

In other words, replacing the check with numbers:

System       | Free RAM (Pages) | Gate (Pages) | Free < Gate? | Result
-------------|------------------|--------------|--------------|-------
8GB          | 20,480 (80MB)    | 22,946       | 20480 < 22946| RUNS
16GB         | 1,832,740 (7.1G) | 45,894       | 1.8M < 45k?  | BAILS


Carlos

> +static inline bool zone_maybe_fragmented_in_shrinker(struct zone
> *zone)
> +{
> +	/*
> +	 * Simple heuristic: if the number of free pages is more
> than twice the
> +	 * high watermark, this may suggest that the zone is heavily
> fragmented.
> +	 * When called from a shrinker, aggressively evicting memory
> in this case
> +	 * may do more harm to overall system performance than good.
> +	 */
> +	return zone_page_state(zone, NR_FREE_PAGES) >
> +		high_wmark_pages(zone) * 2;
> +}
> +
>  #ifdef CONFIG_NUMA
>  static inline const char *numa_stat_name(enum numa_stat_item item)
>  {