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 269F6C28B30 for ; Thu, 20 Mar 2025 15:33:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E1E04280002; Thu, 20 Mar 2025 11:33:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DCD2F280001; Thu, 20 Mar 2025 11:33:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C968C280002; Thu, 20 Mar 2025 11:33:21 -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 AD5EF280001 for ; Thu, 20 Mar 2025 11:33:21 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 69C42AC0E9 for ; Thu, 20 Mar 2025 15:33:21 +0000 (UTC) X-FDA: 83242323402.17.CA28116 Received: from out-171.mta1.migadu.com (out-171.mta1.migadu.com [95.215.58.171]) by imf04.hostedemail.com (Postfix) with ESMTP id 8497640014 for ; Thu, 20 Mar 2025 15:33:19 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Ytld5BRz; spf=pass (imf04.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.171 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=1742484799; 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=wBWIFHFRJcaNoFMrG97otHmcDK1seyDFqXM9Jg7jnHA=; b=oDtIHDdKyOdy+75EVn9WKucKSpgj/b39fSqEi0q6cdPqjo2HvseoTRajAwEEDdh6Nk0TbU eknc4YuoqGBuH2n7vDP2AwLsuA/ksElCfPZxD/d0BYRj6QMnR6AOCaEXcJD0QrUVY7VwVz pwrMSjm7yiUFnRbL3BtKIWe94uY0rEc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742484799; a=rsa-sha256; cv=none; b=xRuiiyLDZ92ZpaYQTEnd9QJ93EohM915uzlQf71pNAAUHZuf/YGaGP/eEk2fijp/v462c2 NQwpzbXVUSdm0kJgen/dfMQVdKevb7kVtRryLlg0BvR+bAQtUVKCK860/p3ITA1qBbF6NY jWP95yRtH/qsRZAGEqe5BK42asIHhD4= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Ytld5BRz; spf=pass (imf04.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.171 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Thu, 20 Mar 2025 08:33:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1742484796; 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=wBWIFHFRJcaNoFMrG97otHmcDK1seyDFqXM9Jg7jnHA=; b=Ytld5BRzpnCKlRLYi6Gn0nRcKP8RdSrrUtdOUlnVnY8VjgE9KfoZ/QmqumX0+Nb1h0kFLy qIcLF2AfyZIs3Fq/UYeqbDa8q2Z/zvpBjLwTPyC58BRnph3tIsINK7Oqa0x8pKWGjqkGbl bNetuiMCPEwVKqCy4CK3izeDcCyw9R0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Johannes Weiner Cc: Roman Gushchin , Jingxiang Zeng , akpm@linux-foundation.org, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, mhocko@kernel.org, muchun.song@linux.dev, kasong@tencent.com Subject: Re: [RFC 2/5] memcontrol: add boot option to enable memsw account on dfl Message-ID: References: <20250319064148.774406-1-jingxiangzeng.cas@gmail.com> <20250319064148.774406-3-jingxiangzeng.cas@gmail.com> <7ia4tt7ovekj.fsf@castle.c.googlers.com> <20250320142846.GG1876369@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250320142846.GG1876369@cmpxchg.org> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 8497640014 X-Stat-Signature: 9orxfgnwfb8jcghdtdh6gxfy8jfrd9sz X-HE-Tag: 1742484799-585331 X-HE-Meta: U2FsdGVkX1+JjT7XUr7oCtLkF7uIaQmGO+6pd012Y3q37GOKyBY8AbU/kQUS9rO+nqXhxMg67QiiiuM2gc25KHfriyswGoPE2A8K/zGSdk4r5z+jcAFQeuDacVV1JE4QJvMZ6YT/OrXjvCw8F45YxFQMKEmLy3LfmUuwkcbZ8ldEvgYEf8bv19tE6SKCWOKfdGaGG0jl6QfKeQGDpELOCMeb2otavHiiRAmqFBtqb/wFMrIJWiKHEWCX5srsWaNKE3YCLDIAJzZb75w3hg/UCNlufs2L9/werPs/+Txdfcpj24IyHK4urLJndp6olnWGccAAo6AVYv2RweaHUhrnsrgpZNgL9+QlAB/R3YzpbveEdc4jSxZyyl/In4lLbhdvbemmBsYKbJVlvOUOPXvCnVe08uwXDJlRwbOlDGONBliZNHBrWFqpWPGotIAXWDJ+do59xe78bqHA4R1ipHqACF8xVJ2wFdG9tErmmLK+KVbdLD2rquctWv80jrUhMHUhqb9iVc/CDqCqQ9lGrJQBr8CcMIEEIaNlwylP9k8B9Y7lVMN+PpCRY//t/wQaGjgHqYhDNTjth1v06QgSIf8sf0hbLtd5FWnffBx9g5fF0ywJqk1TNCnaSxQNF5ETf1dcfA3yz/AnuMknlhfDGFo5VsBkeJjzxp+doWuD8Kh88BfcLgRzBnRjxbiBlONNvSqkjNu1/PUB6+1HaKvQyFx74/X43u9bhgAvCjfm1csTd0DhiaAtS24gqpJjqkScxc75EyF7VF2s3zO5iDKACkcngCOcsR+J4wIrHSyX4I5pb2KvlzHC8r38yEevYi7KuYQm46kBh4QFNIykvkgBSt4yWAjm0SqvAKuO8U2kpfQIirSufulzdvCWK0j7mdgoMJ04EbuGTkUPS+itsXgev+v+Yq4+ogaAX3Tjeh/3tf+2304rOru5I8QiYwbyFJAfT6CHEr9zhccAJ1sOtV4aE8k Pyjb9A/r AfT49OS/VjzCBJ9VFQbn9PbGJhT3clZ170VVTOITTfJ4cvczOOcUInxKukslvdLeEmuUOep5R7X/eh4/25EZsulqqbEjnrDGgWIdVlK6mZLMC+KLZPG65Yv9yjpv6KMcCHC41F7EBZ0zMVsa4ldg2rGGYJczQGZhyuf/ghS4to7Kgr7c3Ixj4TABRUC85z3/5ZlIRvu4FB3eaRn0= 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 Thu, Mar 20, 2025 at 10:28:46AM -0400, Johannes Weiner wrote: > On Wed, Mar 19, 2025 at 10:30:20PM +0000, Roman Gushchin wrote: > > Shakeel Butt writes: > > > > > On Wed, Mar 19, 2025 at 02:41:45PM +0800, Jingxiang Zeng wrote: > > >> From: Zeng Jingxiang > > >> > > >> Added cgroup.memsw_account_on_dfl startup parameter, which > > >> is off by default. When enabled in cgroupv2 mode, the memory > > >> accounting mode of swap will be reverted to cgroupv1 mode. > > >> > > >> Signed-off-by: Zeng Jingxiang > > >> --- > > >> include/linux/memcontrol.h | 4 +++- > > >> mm/memcontrol.c | 11 +++++++++++ > > >> 2 files changed, 14 insertions(+), 1 deletion(-) > > >> > > >> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > > >> index dcb087ee6e8d..96f2fad1c351 100644 > > >> --- a/include/linux/memcontrol.h > > >> +++ b/include/linux/memcontrol.h > > >> @@ -62,10 +62,12 @@ struct mem_cgroup_reclaim_cookie { > > >> > > >> #ifdef CONFIG_MEMCG > > >> > > >> +DECLARE_STATIC_KEY_FALSE(memsw_account_on_dfl); > > >> /* Whether enable memory+swap account in cgroupv2 */ > > >> static inline bool do_memsw_account_on_dfl(void) > > >> { > > >> - return IS_ENABLED(CONFIG_MEMSW_ACCOUNT_ON_DFL); > > >> + return IS_ENABLED(CONFIG_MEMSW_ACCOUNT_ON_DFL) > > >> + || static_branch_unlikely(&memsw_account_on_dfl); > > > > > > Why || in above condition? Shouldn't it be && ? > > > > > >> } > > >> > > >> #define MEM_CGROUP_ID_SHIFT 16 > > >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > >> index 768d6b15dbfa..c1171fb2bfd6 100644 > > >> --- a/mm/memcontrol.c > > >> +++ b/mm/memcontrol.c > > >> @@ -5478,3 +5478,14 @@ static int __init mem_cgroup_swap_init(void) > > >> subsys_initcall(mem_cgroup_swap_init); > > >> > > >> #endif /* CONFIG_SWAP */ > > >> + > > >> +DEFINE_STATIC_KEY_FALSE(memsw_account_on_dfl); > > >> +static int __init memsw_account_on_dfl_setup(char *s) > > >> +{ > > >> + if (!strcmp(s, "1")) > > >> + static_branch_enable(&memsw_account_on_dfl); > > >> + else if (!strcmp(s, "0")) > > >> + static_branch_disable(&memsw_account_on_dfl); > > >> + return 1; > > >> +} > > >> +__setup("cgroup.memsw_account_on_dfl=", memsw_account_on_dfl_setup); > > > > > > Please keep the above in memcontrol-v1.c > > > > Hm, I'm not sure about this. This feature might be actually useful with > > cgroup v2, as some companies are dependent on the old cgroup v1 > > semantics here but otherwise would prefer to move to v2. > > In other words, I see it as a cgroup v2 feature, not as a cgroup v1. > > So there is no reason to move it into the cgroup v1 code. > > Agreed. Let's think of this proposal as making memsw tracking and > control a full-fledged v2 feature. > Sounds good. However I want us to discuss and decide the semantics of memsw from scratch rather than adopting v1 semantics. Particularly I don't like the failure of setting memsw limit on v1. Also we should discuss how memsw and swap limits would interact and what would be the appropriate default.