Received-SPF: pass (google.com: domain of linux-kernel+bounces-175379-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240509034138.2207186-1-roman.gushchin@linux.dev>
 <jf44dfyaenz6xmn2hcodaginrshw5d5hfhmakdxtj4x6szk6b2@cr2rxamkgj2m> <edff9a60-a77f-bc6c-3d07-4f96a97f1e38@google.com>
In-Reply-To: <edff9a60-a77f-bc6c-3d07-4f96a97f1e38@google.com>
From: Chris Li <chrisl@kernel.org>
Date: Fri, 10 May 2024 00:10:53 -0700
Message-ID: <CAF8kJuPpuRezs-HwF7E4a_GaLU55GoSvQfYVK3=ga+ZiJ5kFtQ@mail.gmail.com>
Subject: Re: [PATCH rfc 0/9] mm: memcg: separate legacy cgroup v1 code and put
 under config option
To: David Rientjes <rientjes@google.com>
Cc: Shakeel Butt <shakeel.butt@linux.dev>, Roman Gushchin <roman.gushchin@linux.dev>, 
	Andrew Morton <akpm@linux-foundation.org>, Muchun Song <muchun.song@linux.dev>, 
	Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@kernel.org>, 
	Matthew Wilcox <willy@infradead.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, 
	gthelen@google.coma
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 9, 2024 at 7:59=E2=80=AFPM David Rientjes <rientjes@google.com>=
 wrote:
>
> On Wed, 8 May 2024, Shakeel Butt wrote:
>
> > Hi Roman,
> >
> > A very timely and important topic and we should definitely talk about i=
t
> > during LSFMM as well. I have been thinking about this problem for quite
> > sometime and I am getting more and more convinced that we should aim to
> > completely deprecate memcg-v1.
> >
>
> I think this would be a very worthwhile discussion at LSF/MM, I'm not sur=
e
> if it would be too late for someone to make a formal proposal for it to b=
e
> included in the schedule.  Michal would know if there is a opportunity.
>
> I say that in light of
> https://lore.kernel.org/bpf/ZjL5b-zipMrV2JSg@archie.me/T/#mb6c21b09543c43=
4dd85e718a8ecf5ca6485e6d07
> as well for the whole cgroup v1 -> v2 transition.
>
> Chris, now cc'd, would know best about all of the dependencies that Googl=
e
> has for memcg specifically.

Thanks David,

Yes, I am very interested in that cgroup v1 -> v2 transition discussion.
>
> > More specifically:
> >
> > 1. What are the memcg-v1 features which have no alternative in memcg-v2
> > and are blocker for memcg-v1 users? (setting aside the cgroup v2
> > structual restrictions)

In the list mentioned by Roman: "soft limit reclaim, oom handling in usersp=
ace,
complicated event notification system, charge migration."

The "oom.control" and leak of user space oom control is a big one for googl=
e.
Some test frameworks also use "memory.force_empty".
Soft limit reclaim and charge migration is also used.

There is also the combined "memsw" limit enforcement. Google has some
internal work around for V2 but it would be good if that upstream can
support it directly.

BTW, I know you are not looking for the "cgroup v2 structure restrictions".
Two cgroup controllers that can't have different sets of processes is
a bit too restrictive.

That is what I recall right now, I might be missing some small odd items.

Anyway, glad to join the discussion if there is a session.

Chris


Chris
> >
> > 2. What are unused memcg-v1 features which we should start deprecating?
> >
> > IMO we should systematically start deprecating memcg-v1 features and
> > start unblocking the users stuck on memcg-v1.
> >
> > Now regarding the proposal in this series, I think it can be a first
> > step but should not give an impression that we are done. The only
> > concern I have is the potential of "out of sight, out of mind" situatio=
n
> > with this change but if we keep the momentum of deprecation of memcg-v1
> > it should be fine.
> >
> > I have CCed Greg and David from Google to get their opinion on what
> > memcg-v1 features are blocker for their memcg-v2 migration and if they
> > have concern in deprecation of memcg-v1 features.
> >
> > Anyone else still on memcg-v1, please do provide your input.
> >
> > thanks,
> > Shakeel
> >