Re: [PATCH rfc 0/9] mm: memcg: separate legacy cgroup v1 code and put under config option

[David Rientjes <rientjes@google.com>]

On Wed, 8 May 2024, Shakeel Butt wrote:

> Hi Roman,
> 
> A very timely and important topic and we should definitely talk about it
> 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 sure 
if it would be too late for someone to make a formal proposal for it to be 
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/#mb6c21b09543c434dd85e718a8ecf5ca6485e6d07 
as well for the whole cgroup v1 -> v2 transition.

Chris, now cc'd, would know best about all of the dependencies that Google 
has for memcg specifically.

> 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)
> 
> 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" situation
> 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
>