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

[Vlastimil Babka (SUSE)]

On 4/30/26 09:47, Thomas Hellström wrote:
> On Wed, 2026-04-29 at 19:47 -0700, Matthew Brost wrote:
>> 
>> 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.

I'm not sure I understand your concern wrt cgroups, but some hopefully
relevant (and hopefully not wrong) points:

- fragmentation is a zone-related property, not cgroup
- hitting a cgroup limit doesn't wake up kswapd nor go through the usual
reclaim/compaction paths, it's a form of direct-reclaim-only

So I believe it should be easy to recognize when your shrinker is called for
memcg shrinking and not kswapd and thus it can't be happening due to zone
fragmentation but must be due to memcg limits, and then you probably don't
need to check zone_appears_fragmented() at all.

> 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