Re: [PATCH 0/2] mm/vmpressure: reduce CPU, memory and code overhead on cgroup v2

[Usama Arif <usama.arif@linux.dev>]

On 08/06/2026 18:05, Shakeel Butt wrote:
> On Sat, Jun 06, 2026 at 04:41:32AM -0700, Usama Arif wrote:
>> The vmpressure subsystem has two distinct consumers, gated by the
>> @tree argument:
>>
>>   tree=false : in-kernel socket pressure, consumed by TCP/SCTP. This
>>                is cgroup v2 only; v1 sockets read memcg->tcpmem_pressure
>>                instead.
> 
> We should really move v2 away from vmpressure.
> 
>>   tree=true  : cgroup v1 userspace eventfd notifications via the
>>                memory.pressure_level / cgroup.event_control interface.
>>                v2 has no equivalent (userspace gets reclaim signals
>>                through memory.pressure / PSI, which doesn't touch
>>                vmpressure).
>>
>> So of the four (hierarchy, tree) combinations, only two carry data
>> that anyone reads. The existing early return in vmpressure() covered
>> v1 + tree=false; the symmetric v2 + tree=true case was falling through
>> and doing the full lock / accumulate / schedule_work / parent-walk
>> dance, even though the events list it eventually iterates is empty
>> on cgroup v2 (vmpressure_register_event() is wired up only through the
>> v1 cftype "memory.pressure_level" and can't be reached from a v2
>> memcg).
>>
>> Patch 1 extends the existing early return to also skip v2 + tree=true.
>> On a v2-only host this eliminates a contended path where reclaimers
>> can serialize on a single global sr_lock. bpftrace on a 176-core production
>> host (cgroup v2, 285 memcgs, sustained reclaim) showed ~16,200 such calls
>> per minute with tree = true.
> 
> This is good.
> 

Thanks!

>>
>> Patch 2 follows up with a cleanup: it splits the v1 userspace eventfd
>> interface (struct vmpressure_event, the events list and its mutex, the
>> work_struct and its handler, the parent walk,
>> vmpressure_register_event / unregister_event, and vmpressure_prio)
>> into a new mm/vmpressure-v1.c built only when CONFIG_MEMCG_V1=y,
>> behind small no-op stubs in the header. mm/vmpressure.c keeps the
>> shared bits and the tree=false socket-pressure path. The size of
>> vmpressure.c goes down to half and the code is much more simpler.
>> The only #ifdef CONFIG_MEMCG_V1 remaining in source is around the
>> v1-only fields inside struct vmpressure itself. Memory savings on
>> CONFIG_MEMCG_V1=n:
>>   struct vmpressure :  112B  ->  24B
>>   struct mem_cgroup : 1664B  -> 1536B
> 
> For this, I am wondering if we should just go ahead and work towards making
> vmpressure memcg-v1 only unless we foresee a lot of or complex work is needed
> for that and only then patch 2 makes sense.
> 

I think there might be a transition needed? Because vmpressure and PSI
do not work out to be the same and people might notice a regression with
increased memory usage or a hit in networking performance and might want to
opt out? A solution might be to switch socket pressure to PSI while
keeping vmpressure around gated by a defconfig. And then in a few releases
remove it completely for cgroup v2 if no one complaints. If we go down that
path, we would need patch 2 for the medium term.