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 51922C36000 for ; Thu, 20 Mar 2025 08:09:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BFE09280002; Thu, 20 Mar 2025 04:09:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B883D280001; Thu, 20 Mar 2025 04:09:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A00CF280002; Thu, 20 Mar 2025 04:09:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7EC9A280001 for ; Thu, 20 Mar 2025 04:09:43 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 9E5DA1A10BA for ; Thu, 20 Mar 2025 08:09:43 +0000 (UTC) X-FDA: 83241205446.25.4BA38B6 Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by imf14.hostedemail.com (Postfix) with ESMTP id C063A10000B for ; Thu, 20 Mar 2025 08:09:41 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PKvoK+Bi; spf=pass (imf14.hostedemail.com: domain of jingxiangzeng.cas@gmail.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=jingxiangzeng.cas@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742458181; 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=JMhkC/qzy7CJY247FAczSaMR9th3O24RtFPlon4S9k4=; b=kEzflmQ24M0NJeeolk9bUrhsZKjI3Oy2BQreTMb8H9IIfAb+dMPuJ6JpBs8w/ARFRW2G28 x2Ud3766Qskh0tPxwUZ2j/hU5JJyv10mld4HYq1GC3e4pt/rgrZkyyw60eGIVNr5QikvmG mLxuQGu2XbsU1U+6RgZ7DTNYmMycr+E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742458181; a=rsa-sha256; cv=none; b=YpbjuehUqzXIXr17U3b732AjyvtzEBuSO6Ejb1YeGwxwieNK/++iKmT4mzVfqBjMka4vdg Iv0b5IXiuCCPZUPR8OhQW0elN5MagxE0gBV2bif1r5v6OzNALWKWu81KK8IsDSNF531m0v eZCwCu0OEq/1p73emzwnzDXMNidPGwQ= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PKvoK+Bi; spf=pass (imf14.hostedemail.com: domain of jingxiangzeng.cas@gmail.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=jingxiangzeng.cas@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-3012885752dso817601a91.2 for ; Thu, 20 Mar 2025 01:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742458180; x=1743062980; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JMhkC/qzy7CJY247FAczSaMR9th3O24RtFPlon4S9k4=; b=PKvoK+BiUA4DsM8PsD/gRSTIt1HaZTfDFSJpl1OHLohtIQceuOFFvfy7FEZGFBSnqZ 7kPjBUewC236nly7E9tDCDWrj3/+unBSIB4V8Q2OfVfATFIlCTwz88Qz9Zzt40ya7qj9 L0N0Svu93Zh4EPyjdmKrDblt9y3lTNh2UE7Y+2BAvDLwped+8RK5tiePCNcImZewEwqA OHN+lhvG7z/jWXeO/6x1nnjXa/Z1wqkvbCZd/q0DLAyCCvnzmRRno71rqjwwef6Y3pZF CFC+jck4q6JiSePN7TLEO0nmrDASe8XNOsbTOQPUb5GtI9ExdFm2+K1zf0bf8TqXYo7N ybPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742458180; x=1743062980; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JMhkC/qzy7CJY247FAczSaMR9th3O24RtFPlon4S9k4=; b=c2vXu97M87KqziO9423UG4xGRxZvhsKv/7c3Gb8nsWs5jn1ChjidXMdfInDrx+t+vt W/jiJcM9OzM3nrv/vj6u/jbo9K+IrV1IHj8/JBsOOIgPFcHWPrHNQQRNXFH8rrixqxWs G63hpGKWx3GTFaQSSwW4Ky2XNtyTjcZ495zFxtbxnIU7stYGXE0obbvJhgkyx4hiZ8ql oS0Gypcl6p4uqkNlDVG9MfMWddcrUmeLhZco8lkJixjjy6FPogbR0SFIH7BIN6C2Zugl W8c5NLt97CrVUiVvqX5DzW+nOa/YwQIxIxi5BX7Q3UkJRH9MFNQOTTqCUOm2QTn6azwj odrA== X-Forwarded-Encrypted: i=1; AJvYcCUhlzVEee3vI3BQbLNa8l6oHqBAtRmqnIN9FwC4uoc5Mg84m38G9V0aamCnkXyFQrR0vQsa52mPvQ==@kvack.org X-Gm-Message-State: AOJu0YxmwtHzJdDpl+4+nTHDa0zt/EZ63is6/dZFg0ycHi4tMZvS77Yu NvBwixZ5+82hd6Wgze6zuTR8F+04REy0AHCaHSmFW+L7mkCYyUAH0TxzTdCVD2W9YHMsmdpoX/e f90VuWegouIPBe74AZfZsROeNRo8= X-Gm-Gg: ASbGncv5fkxLw7YkAR1P1IKNALXGKY7Qas2096Mo54//pDvIAA2p14X4NKRi7hJo87+ gOEXKRDTU9hdPXs2YKH9huLxYF3mUFa/SHPuEGaixA+7V9Gr9o68CvddTwAwMye+kdIPiO9MwdF 20cJ/6Y2NsDDLooFy7EQaOhHJqkQ== X-Google-Smtp-Source: AGHT+IEQiTKOt2LMSqy3PQHK3F1M7BdfLFWEHQ4J+Jl93iXKf+ApncxDTs9g4rgwDvOjOKsh5oKBLX2x98Ctz5xOddg= X-Received: by 2002:a17:90b:5285:b0:2fc:c262:ef4b with SMTP id 98e67ed59e1d1-301bdf93e0cmr10361659a91.18.1742458180445; Thu, 20 Mar 2025 01:09:40 -0700 (PDT) MIME-Version: 1.0 References: <20250319064148.774406-1-jingxiangzeng.cas@gmail.com> <20250319193838.GE1876369@cmpxchg.org> In-Reply-To: <20250319193838.GE1876369@cmpxchg.org> From: jingxiang zeng Date: Thu, 20 Mar 2025 16:09:29 +0800 X-Gm-Features: AQ5f1JrZZEoKedaMtWNsJLn9ST0hUA5wF5GIy5JQ7u50GlSaaHdntRsri3F9-y8 Message-ID: Subject: Re: [RFC 0/5] add option to restore swap account to cgroupv1 mode To: Johannes Weiner Cc: akpm@linux-foundation.org, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, kasong@tencent.com, Zeng Jingxiang Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: C063A10000B X-Stat-Signature: istefny9eqcjjnr55axx7ci9bbjjirn4 X-HE-Tag: 1742458181-103065 X-HE-Meta: U2FsdGVkX1+3dkRdzKYtMLFbpRbjbwRLbVKcPQGRVxBqZV+zc37G+c9/rrf8XA5Ty2D+rYC4EpMMHHe4qNOCP6sFya3MglwHtI7ZPDQ/Ou5fUkbIhjmKd19YW3UXy/pdRzZxbCyDpz7VxV+U4UF2Oc7eR4/Nd7YyZ88/GHpfhcXQpWD+MLp9U3/ldx0CAYETZmNAXsnC2IgoJsYv0BduOAwpbocxa4Wjon0Wf4wk98z+lg1+GY6A2Q1Uk8RGJ+lTfdXYDxyoKcc+Z6uI2XBqnO7gatVz+Zzegp9COdLq4d8gMuD5aN2sY+ZSOoGohb1JqTz/4rikJ1DAoK/HpP4eIKjTa/igWGtxQZM23LOqmKeZfK5k7Q3bYlse/SClq/7Px5cPivIilIDXzkaZyh4/xy/A6b1B+0JGOMmmwyf8LsvWoqgU8EM0TsRs76opBmrau/5P8/MNH09ceLyE4D8HqISWveY2bK1Kahc65pk7EUIsO5P1CplL4pVOsYJRtml1oP7PUFuNAyOtUfgwRsQPWS51Q21CdQz+AtpP/0Ll7yRyqgByrWWrpPWVbDMWj9ImsbZXg1KBbwk/4ExfakvRaXrv9uGSQaQo9j03nDTPvuqkXtDWvhh8l9H4VojaOeAtaaSjAHMpXzEtN6r4aIU+JBapH1jHRAI0ue6dXBRsLOO4DxwKw1QoyGHRQbO0tIkvHAeJI9V4ghpTqUwbXof3SnYNnffpAekIdhbU17N6+M712GzJhKpF+FTjgz1g++26n+0CJMwt6QmrJbZLXQhSQ7LaQrjcSHN5+5OEvYHw2qyDhDcZ0oIemDI3TK8c0ymDiF3SF296MgqkuAVHJjmmGAiXblBwz1SnMME5MwTM9n/mcpYfRtQjrTrVJcLHgdWq7uNHauhfY7uocjVQaf2j6bwaJJ3uP06nn0BEyanf670ExBh7wra+uCV9AQweEVOZqJXpUPEDfDrMHO/Y4hO 5ZW7enMD mCI8GdEde2wfKsCh/af4T2MhyyIuluUw9CUYZqoKIrpDKm58RkAbup3JJT+29055u6YpZx+dlvWCER3746+vsq9GpuotEw8n1GFpf4y1wIiPewhwX9ZD8UEcA6QI6Bou3Tx8MBVFjXi1aDXel+osdOneX8PhptO3fhjxVkTNjpxsxkGWIJFYtf5ZDInFZEkUX3w5F1od2msEsh7b6h5nhmRMl+xZbcR5wqjPDeAb6lKdp+w/uom61QDvwUHIKDE4h9yqExTiN8fxsH9SAwCyFPFQRVlVLRQPc3Np6K0FAosDILt82USdzgW5P/tVBY0nueWmBVBC/e0hZm5yamAQp9wAnrLYq/9vmafuwGWt0FCouWiCG1CsNgSk+WlAbLjr3QKoLcL/cm2slp6AXPBYb/lsUZTjUe4yW2388hJWlN+Cz44s/P0wYkKDm5IzXW7iwXUVr4yolC8YFY9o= 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, 20 Mar 2025 at 03:38, 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. Hi Johannes, If both memsw.max and swap.max are provided in cgroupv2, there will be some issues as follows: (1. As Shakeel Butt mentioned, currently memsw and swap share the page_counter, and we need to provide a separate page_counter for memsw. (2. Currently, the statistics for memsw and swap are mutually exclusive. For example, during uncharging, both memsw and swap call the __mem_cgroup_uncharge_swap function together, and this function currently only selects a single counter for statistics based on the static do_memsw_account. As mentioned above, this patch set considers the approach suggested by Roman Gushchin[1], which involves switching to cgroupv1 behavior through a configuration option, making it easier to implement. Link: https://lore.kernel.org/all/Zk-fQtFrj-2YDJOo@P9FQF9L96D.corp.robot.car/ [1]