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 94AC0C10F1A for ; Thu, 9 May 2024 06:33:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E0236B0089; Thu, 9 May 2024 02:33:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0914E6B008C; Thu, 9 May 2024 02:33:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC0E26B0092; Thu, 9 May 2024 02:33:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id CF53E6B0089 for ; Thu, 9 May 2024 02:33:17 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7A23CA1288 for ; Thu, 9 May 2024 06:33:17 +0000 (UTC) X-FDA: 82097890434.10.D9EBED2 Received: from out-175.mta1.migadu.com (out-175.mta1.migadu.com [95.215.58.175]) by imf03.hostedemail.com (Postfix) with ESMTP id 8A66620007 for ; Thu, 9 May 2024 06:33:15 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Wv+vaHy4; spf=pass (imf03.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.175 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715236395; 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=UHtr7m6si+trM2Dv317fWhouVoPBtQqoBHj5VW99r0A=; b=mxXUNbuHA0/hCsnBlbnKaev/nsKB4+pElN/9dGIGQ+LCJ/HCUkOTw8nnd9QVarbWpR+02z eXy8lJk68hYu8Q+oH+CMVVxP3Sy/4jvxWhVrI9CfSHmtx6ugnrf/thCn8segiMKzkyGQMA 1svJdJsOnreR/lRx2LxlEq4rJ4XAakU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715236395; a=rsa-sha256; cv=none; b=HrmHge2Rem47KuoEjp6Ob6T/LfSD+i7SOHJbTIaGOoVDLGFkuCe3mYpzA7lMYWRIcHOK4b cXtOzWcbbcmpFEipljHbRocQDV3EMh6Nw6wIruOVs0gMkYqa7eaJ8dYfy+l/DeHBgo76L0 /9PaderzVWQsUcR0567ctTrnDyTLcUc= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Wv+vaHy4; spf=pass (imf03.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.175 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 8 May 2024 23:33:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1715236393; 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=UHtr7m6si+trM2Dv317fWhouVoPBtQqoBHj5VW99r0A=; b=Wv+vaHy4pFsFYU7gj/FuDvS5+mWemGN38atWuybzD/uHeaBVhzqHleqn2k+R+Q12jHQvTf nyMsl1E8GnEBMtm8XvOde/W0Px6jtQF0nvTKt6VxYytOmIh6AWass6MZ2SO0n36ThNP5GO 1GeheQHHeCsHtv/BuWPCzQSJWr4+A3U= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Roman Gushchin 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: <20240509034138.2207186-1-roman.gushchin@linux.dev> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Stat-Signature: soihhwe74p1utbxtmhfddgr1fx1wbju4 X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 8A66620007 X-HE-Tag: 1715236395-638723 X-HE-Meta: U2FsdGVkX19zU9fMn/vArt4D0XsLyRdcn9D1XWl8krwaKFtsmq4v5hs2rp7x/SC1HOZSXXufKLZQ8VF/7tzJ2gD4InGWjEmj76Id/Wh2yIH3JznFI6BA15yuse/pHVGxbIBs9khBXdyqiFX+lKeuPdm4ACtyzqNR/2WwLtCJ1Lry7CVZV34OG9zsRys4aFMifGNc6ooGvQD7rSaG5d2gjMnAM00U+J+oQqZKdbjsGk0qqxKmhdBokgMHDqxjzcFZNzrpA3Yb+LWoBLu4bxafInm9g6xw6cixfaC8ZHu707/VcCga42FgJZtmmQfdNV3p4GgtvD7U7rnPFly04Yj6bRBOfhbesVuc0voZMj+An4uM6KlFVmJn8c8lhI88rQWhJdEKbdeKYDoeIwUgIkUErIc4uGhkmml0krSMp5gJGWRwpAn4JlElnxNN8r5zJGKQhBonljBUR7C1YIwCCyQKsE3HusOBEnrVNjQdPPvlcOtQEw/OoCdmOPXBxs71KRqHzcYY6fM3yMZchn4HM8BHspFkNlQJLjhqcOenWXb3ID2LYyPf4v4qZMmcEEME+muBbQwJIdAhCKpiE6bYqkB1/dsu+SRtqu709MN76CzlC7o9esxcg7C/+Qrm9rKQZv5smolQm7FnJdxTDV2/QsBPoV2AAc6AYbeqrrRup/Hdepu97THxyMmKjSmP+41HCcjIV30fusgIJA8k/WVHT1n+jZarY+3Ks08CNeuf6l6+dVUDPgFQXQfeIL7ZkTF9JJasZ6HciGS9R15mqfs0JIlmJ2vm276tm1hGAAL7jO1x+bpX0UBIBJfJAgzVIVdw76qhiqUnws2+YnB78MvrE9Od1c6mBnz5/C8HK1jEBRLtCxYW+4JfUqpULopTyLMLoG1pdFGMBinvSKuw/Zf0WCn5lE6/+BY/MCnrAXtTgvPy9J02FM7KMBlcuxjr2yw3DCqN8ZbTBXLYtJVEv+Xc/fD dn/kBQpG mnk0at3qVbPydJnfBT8vxmD5y5CQ5KQPPV2ZqthhJ0U0AMHUqrnp+p6GpgOoUf4cjGd4YSKx66swFKRs= 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 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) 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