On Thu, May 9, 2024 at 7:59 PM David Rientjes <rientjes@xxxxxxxxxx> wrote: > > 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@xxxxxxxxx/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. 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 userspace, complicated event notification system, charge migration." The "oom.control" and leak of user space oom control is a big one for google. 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" 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 > >
