On Wed, May 08, 2024 at 11:33:07PM -0700, Shakeel Butt wrote: > On Wed, May 08, 2024 at 08:41:29PM -0700, Roman Gushchin wrote: > > Cgroups v2 have been around for a while and many users have fully adopted them, > > so they never use cgroups v1 features and functionality. Yet they have to "pay" > > for the cgroup v1 support anyway: > > 1) the kernel binary contains useless cgroup v1 code, > > 2) some common structures like task_struct and mem_cgroup have never used > > cgroup v1-specific members, > > 3) some code paths have additional checks which are not needed. > > > > Cgroup v1's memory controller has a number of features that are not supported > > by cgroup v2 and their implementation is pretty much self contained. > > Most notably, these features are: soft limit reclaim, oom handling in userspace, > > complicated event notification system, charge migration. > > > > Cgroup v1-specific code in memcontrol.c is close to 4k lines in size and it's > > intervened with generic and cgroup v2-specific code. It's a burden on > > developers and maintainers. > > > > This patchset aims to solve these problems by: > > 1) moving cgroup v1-specific memcg code to the new mm/memcontrol-v1.c file, > > 2) putting definitions shared by memcontrol.c and memcontrol-v1.c into the > > mm/internal.h header > > 3) introducing the CONFIG_MEMCG_V1 config option, turned on by default > > 4) making memcontrol-v1.c to compile only if CONFIG_MEMCG_V1 is set > > 5) putting unused struct memory_cgroup and task_struct members under > > CONFIG_MEMCG_V1 as well. > > > > This is an RFC version, which is not 100% polished yet, so but it would be great > > to discuss and agree on the overall approach. > > > > Some open questions, opinions are appreciated: > > 1) I consider renaming non-static functions in memcontrol-v1.c to have > > mem_cgroup_v1_ prefix. Is this a good idea? > > 2) Do we want to extend it beyond the memory controller? Should > > 3) Is it better to use a new include/linux/memcontrol-v1.h instead of > > mm/internal.h? Or mm/memcontrol-v1.h. > > > > 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. > > 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) I don't think there are any, except there might be a certain cost to migrate, so some companies might be resistant to put in resources, because they don't see any immediate benefits as well. > > 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. I'm not sure we want to deprecate them one-by-one - it's a lot of work and maybe we can deprecate it all together instead. I think the only feature which we might want to deprecate separately - it's the charge migration. It's the most annoying feature as it requires a lot more synchronization, which can be dropped otherwise, so it's complicating a lot of things. Other features are more or less self-contained. > > 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. Yeah, it's really only a first step. > 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. My rough plan here: 1) move it out to a separate file and put under a config option, default on 2) clean up all remaining small bits here and there ... < wait a year > 3) flip the config option to be off by default ... < wait another year or two > 4) drop the code entirely > > 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. Thank you!
