Messages in this thread | | | Date | Thu, 9 May 2024 19:59:19 -0700 (PDT) | From | David Rientjes <> | Subject | Re: [PATCH rfc 0/9] mm: memcg: separate legacy cgroup v1 code and put under config option |
| |
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 >
| |