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. > 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 >
