From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E6A8C25B10 for ; Thu, 9 May 2024 17:30:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 852946B0088; Thu, 9 May 2024 13:30:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 802666B0089; Thu, 9 May 2024 13:30:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C9AA6B008A; Thu, 9 May 2024 13:30:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 50FFA6B0088 for ; Thu, 9 May 2024 13:30:39 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 04780402BE for ; Thu, 9 May 2024 17:30:38 +0000 (UTC) X-FDA: 82099546998.02.BF01DD7 Received: from out-180.mta0.migadu.com (out-180.mta0.migadu.com [91.218.175.180]) by imf07.hostedemail.com (Postfix) with ESMTP id EE65740022 for ; Thu, 9 May 2024 17:30:36 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="Y0/Jv7Ws"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf07.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.180 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715275837; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CR5MI5JJxqhgz4d1vy4O0Yhzl9P6rPqnDar/P7tXMBE=; b=Qa82EUQ8eDPcSqhqO6R28mamn3MKAAIFy17YVhcaByOf67YbuF1W/lSZy5YnCBS2kT76Av X8BO0uVS83E1Tdl53VpxHAEye5/KS9UDZGXxcc2e7fI9socKR3EjKwmTgZed1Y2gnLfMAq tpqZx8O2+s4KVRURJZqo0/69dntQUDY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715275837; a=rsa-sha256; cv=none; b=5AuuLoAcNlfK1YiSfWxzVP+fTsrnE9hovy4kdjS2HcUI4+Rx9/Y6bskaAxJN8etP02OEEa GHhL3OrjKhw0mgTYXysIDgIODjDFFahwVMkeC7WtPouVEorD2Bwrmc17L3moQxXC5sumJp 6wgb3wT0mUf2ODOjb/xI5pUDmEddW38= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="Y0/Jv7Ws"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf07.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.180 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev Date: Thu, 9 May 2024 10:30:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1715275834; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CR5MI5JJxqhgz4d1vy4O0Yhzl9P6rPqnDar/P7tXMBE=; b=Y0/Jv7WsJjKtJjtcykMElMphU2520hoRqAgMKNsvx6b+RHQCdTDZrZIYnpQ08CEDzf5JWB AC5+JBP5H8Xza5UPjHpDLSnwB4itsPjNtWJQnA6bHp0KFA+dvRZJ4HPzUkwj7aCfi4SgQo 6LpQ2wUMiM4nN0PV1ikYKKF3wDZ4DKY= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Shakeel Butt Cc: Andrew Morton , Muchun Song , Johannes Weiner , Michal Hocko , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org, gthelen@google.coma, rientjes@google.com Subject: Re: [PATCH rfc 0/9] mm: memcg: separate legacy cgroup v1 code and put under config option Message-ID: References: <20240509034138.2207186-1-roman.gushchin@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: EE65740022 X-Stat-Signature: sqx784djju3a7khext5spi1qfx5k8wty X-Rspam-User: X-HE-Tag: 1715275836-785948 X-HE-Meta: U2FsdGVkX19yn0Ri5eyenRbC1ZHuzaOoF51VckBZMZ53y8m9zXtR5gwSaGyEvJhpC9hxsB+/ZzW/KzZMQuZm9MYUR6kRfXk2TTr/aMKaa/mUJz1Zi/+rKrNej6GyVBtK9i+uimd0VemWGWHzjIbR9qNA++ri/KrGamF6ETkg5qzxDfdtlCe7p3yZI8bwGYKTwnBPwO2HD1uRPfaYjNH6+65vf8OZVNerJWJFxvne0/2a8iBFNUbzavT2frxi5Jmq55MaxxhchuyTj18S/VNmH1o4rs3OOISnercHnNFJtGH5rizaQQe5f1CscsWKXKlQtaVzxDImwIPLCypLporvKEfJTwMF2G4iwscbScg2vmBYXLKNNzJwsFLb898SFiFL+cprWvhBXkZcVdbdYFQhLP/0+7Y6WEIOZTHQB9auRjdbf4mmTFdkYraCSUgsECv6iORUKE3u/D5/5bZCcpu5/bR1VCLRFfpf98rq7whksJU6FLzza/SRQwjmRUWvow6NM0Rcm2BsxkjFhBML8uZfo8IU8Q0zyw9kfS52U4cL9DSuOSguJcCXkSO7UqElsCgUXKtXzIgtUej4SOAQaH7V5A5WJVBuxEQXOS8HZzgDxlkaBsJIbQjAzzaadEbB0c8VkI4/vSJe+V8YmivLqN3GPwVhrKHvybiY3HYvXTM0uc0F2s8q/zAYeIhOnSe8DphFwahgdP0u9M3fBwBGyD89MWQZZywRcu05Hk0KzapBqiRZB2Ygia6yb9VNrx6sBwBP58hq8CyvwG+Aiw/C4C06JEM1lIkENg4bAJdfxCQKVwk3lR70lb7kzaxCdIJx0QektzXyFVhuv9LeotUxit9XnJy+fPJcURXt4A8u5gifdgXP2NMKQS0Fs3PqYOW8O1I0gs7iGIWpeKhBg6sS36aWw5ZrsLz9LAf58nXUj/DFEzKTuwPhLL1XqJ8fXpv8nFAqqi13kQuGEEbuInc12DT IeaZPaxN bldD/coV4OlmWwLixvxmqfsCQ663Ahd4wrq1KBo3Gb4QgaE5lr+dJjWHvt4kjqQZBgtgThu+LR1TB6tYpNZ1Lmzol4GFIQddcxfn7FdqYCksP4iq92i7S+qGlISS0RS3/NKjdHmdV7A0di7c= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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!