Re: [PATCH 0/2] mm/vmpressure: reduce CPU, memory and code overhead on cgroup v2
From: Shakeel Butt
Date: Mon Jun 08 2026 - 18:30:35 EST
On Mon, Jun 08, 2026 at 10:19:36PM +0100, Usama Arif wrote:
>
>
> On 08/06/2026 20:56, Shakeel Butt wrote:
> > On Mon, Jun 08, 2026 at 07:49:45PM +0100, Usama Arif wrote:
> >>
> >>
> >>>
> >>> 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.
> >
> > Yeah the reasoning that PSI is not an exact replacement for vmpressure makes
> > sense and it will take couple of iterations to transition v2 (networking) away
> > from vmpressure. Can you please update your commit message with this and about
> > the midterm or transition plan.
> >
> > I assume eventually we will just have vmpressure-v1.c file which will be behind
> > MEMCG_V1 flag, correct?
>
> Yes.
>
> How about something like below in the commit message? :
>
> This split is the first step toward eventually making vmpressure
> CONFIG_MEMCG_V1 only. The v2 in-kernel socket pressure path
> (tree=false) cannot be removed today immediately: PSI is not an
> exact replacement for vmpressure, and switching networking socket-buffer
> back-off to PSI may regress networking performance or increase memory pressure
> in workloads that today rely on vmpressure's hysteresis. The medium-term plan is
> to introduce a PSI-based socket-pressure path, keep vmpressure available for
> v2 behind a defconfig as an opt-out for several releases, and only then
> drop the tree=false path entirely, at which point everything that
> remains in mm/vmpressure-v1.c is the whole subsystem.
>
This looks good to me.