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 8A6BCC35FFA for ; Wed, 19 Mar 2025 19:51:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6781D280010; Wed, 19 Mar 2025 15:51:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6288428000F; Wed, 19 Mar 2025 15:51:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 518A1280010; Wed, 19 Mar 2025 15:51:56 -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 2FBB628000F for ; Wed, 19 Mar 2025 15:51:56 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6B030A96FB for ; Wed, 19 Mar 2025 19:51:57 +0000 (UTC) X-FDA: 83239346274.26.4600B76 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) by imf03.hostedemail.com (Postfix) with ESMTP id 952082000D for ; Wed, 19 Mar 2025 19:51:55 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Lpgz7SGh; spf=pass (imf03.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.174 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=1742413915; 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=aHgZcT1OHid9wj/QcT/hae8vjIoU8PnHq3r0EIbYZD4=; b=sWOolqFqH/TWixztfZoz6iFHIXOSLk+eSDj9a8kOZtb72UeSzdYtIWU5Sywt+HeAV8j3Wm gb+3kJn18r7toZ/GfyTVuEttm/hrKjzG8hwsSdnA4I1ObzFVypAfFbwmaNRYUViiGZOKr+ Iqw0F05W3t9CCfRt6uxO2IzJRc4qGUA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742413915; a=rsa-sha256; cv=none; b=8fpQkyrk2LIamXqOZHqj02z9TEjsg7hkHMqIB2DlumrPy5jbVuaW507FKqiNqVsYOISjtx lPFLCz5ai5lTbkdWsUsN3YT0vEOeh8PTKjKa0T3DkTxQv3xlV918gPxykMTEj8QQM+x949 4rBDuPSp7pkySA3lGsgYB4C1qb4jVOc= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Lpgz7SGh; spf=pass (imf03.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 19 Mar 2025 12:51:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1742413913; 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=aHgZcT1OHid9wj/QcT/hae8vjIoU8PnHq3r0EIbYZD4=; b=Lpgz7SGhCMwypbwd8JKXXD5zkrPvifG4egMIHmtaMFUa8q0QzeszfeGuiKCFCJflpJruT3 rVNcVgU0sm0q7qcNSPpB0bVEG4CjuCxDZXnLUL0fQ+ACwtOHdFmjz0VyO3k1eCqzifiGD1 EEW1XPZllaW2p7yJHw5qH/8WNZUnIiM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Johannes Weiner Cc: Jingxiang Zeng , akpm@linux-foundation.org, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, mhocko@kernel.org, roman.gushchin@linux.dev, muchun.song@linux.dev, kasong@tencent.com, Zeng Jingxiang Subject: Re: [RFC 0/5] add option to restore swap account to cgroupv1 mode Message-ID: References: <20250319064148.774406-1-jingxiangzeng.cas@gmail.com> <20250319193838.GE1876369@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250319193838.GE1876369@cmpxchg.org> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 952082000D X-Stat-Signature: xcrcyyb1qqasnf6nc4rjkg75q5s8wjw4 X-HE-Tag: 1742413915-105100 X-HE-Meta: U2FsdGVkX18oKSY46Nd2iHd22qFo3brwJMItkle0Le+1vfLm2mpbpfWhft/y+HiX9kKNp0vhKqE04bIOe1bGijjbVbwTYpqAEP0OIeQd3oui4gGo4dbLr+Vv6Cg3CTxiq5fnJHM+T8/GzA9Khs0tgcQtZ59agU6fsWhk5xj78lYtO4Qzps672Ecem2cVz+VsJsMF2kxL5KxKSh4knnQS5RlHJFk64bH13VBeyeTqXe1ayq+GnvTCJKMWOGCssOxnxW+Q2jozQVSFxUQ49sXM8FkZRv4Q8hPlOExkZLDTvit0wP/Ohf0CL1YNIBTVghzKEH97q+1QijdFbk+N6i1P0RbJHAU1xtnFvSR4abZTTs/Jw1BfAVlCeikwO+TxKwjF18SYE6UGHA5aNR9D0Pl9nri3yW/xnJ/MluAcBwLElEnvmEmEUsde+7ZiRISUKJ6R8A5tSchMB/x8LCXBtNAfp9AHezj+jJ1ejDI0O8ZZKy+NKn/Zc78kfhZyWxKJ2U6kwYKiiYZbsxf0yH/c4Pj4Pd/IK3cCpR5qwM6khhhKJdbnrYGK6b0HvdibZyqJ9+z8QpazyLVuy3gomiRVahufDXwZisPnv+AM3oRqn8R1T6E6laNCyP/7XM65BlkRN99OzeIT7++15opJqh6xnB01fe69hwoIaUMMq5D5kfprKjcT6NdNHpS0CYXoJC6Gc02eigS7UwQc0iVVsvkqluEvSFmxL7v6MeUzYW7gcmaRgLFSO6zCj5SopnD5m71qqHPgr+3n8t5wO2qSbLzoRCIs1VGTfjZk3vbxOaxslDVQvIPEvZchCeHQbkRkJCBi9slt5dgbreac3HBtdJjpsuZhBwk1Pq7IB0CgrBDlHVEpmOqMijzdv1goi/B551+/otdbwsEDMSbEFYWeDYFwo19ent9uT1KpeXr9Z8A/cDKKcz856Tc7SYYj7LJ4gnOiqWtjpZHrU5OloNlVFrWMz3v TG1qX8da +MWDaec3HJzrK/Xaj6SG7ukziqmLDgcPi/ABimEZgtns7GaAuxO5Cv8Ka4OZMMU/zymoPk7mP8io/xoaz2+1/u5FN3Z2sV6d9bXqVhzWWkBCF8zOVwlyd1f9TXUIRfD+t/mHVmuHsyRSrkvOQQ7v5/6kqE5u9U+5gYamW73+5/C3C6HcXc5IL7NjZpgGoXNcHHNqRVEwBYmPiR7SzBUm7fk0dCtFh1Y7H7pPWRMAQhPuuieLPyqDevS9NXHJchTUC/DsZlVxhazH2IQ5AaBkBNBS/kQ== 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, Mar 19, 2025 at 03:38:38PM -0400, Johannes Weiner wrote: > On Wed, Mar 19, 2025 at 02:41:43PM +0800, Jingxiang Zeng wrote: > > From: Zeng Jingxiang > > > > memsw account is a very useful knob for container memory > > overcommitting: It's a great abstraction of the "expected total > > memory usage" of a container, so containers can't allocate too > > much memory using SWAP, but still be able to SWAP out. > > > > For a simple example, with memsw.limit == memory.limit, containers > > can't exceed their original memory limit, even with SWAP enabled, they > > get OOM killed as how they used to, but the host is now able to > > offload cold pages. > > > > Similar ability seems absent with V2: With memory.swap.max == 0, the > > host can't use SWAP to reclaim container memory at all. But with a > > value larger than that, containers are able to overuse memory, causing > > delayed OOM kill, thrashing, CPU/Memory usage ratio could be heavily > > out of balance, especially with compress SWAP backends. > > > > This patch set adds two interfaces to control the behavior of the > > memory.swap.max/current in cgroupv2: > > > > CONFIG_MEMSW_ACCOUNT_ON_DFL > > cgroup.memsw_account_on_dfl={0, 1} > > > > When one of the interfaces is enabled: memory.swap.current and > > memory.swap.max represents the usage/limit of swap. > > When neither is enabled (default behavior),memory.swap.current and > > memory.swap.max represents the usage/limit of memory+swap. > > This should be new knobs, e.g. memory.memsw.current, memory.memsw.max. > > Overloading the existing swap knobs is confusing. > > And there doesn't seem to be a good reason to make the behavior > either-or anyway. If memory.swap.max=max (default), it won't interfere > with the memsw operation. And it's at least conceivable somebody might > want to set both, memsw.max > swap.max, to get some flexibility while > excluding the craziest edge cases. At the moment memsw and swap shares the underlying page_counter. This would require having explicit page_counter for memsw. What's your take on memsw interfaces still behind CONFIG_MEMSW_ACCOUNT_ON_DFL?