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 3DCD2C36010 for ; Fri, 11 Apr 2025 16:57:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 562CF680012; Fri, 11 Apr 2025 12:57:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 511F068000F; Fri, 11 Apr 2025 12:57:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B184680012; Fri, 11 Apr 2025 12:57:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1C8B468000F for ; Fri, 11 Apr 2025 12:57:54 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C0BC4ACF08 for ; Fri, 11 Apr 2025 16:57:54 +0000 (UTC) X-FDA: 83322370068.16.BC7E87A Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by imf05.hostedemail.com (Postfix) with ESMTP id D5B4710000B for ; Fri, 11 Apr 2025 16:57:52 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=Xv1VgzhL; spf=pass (imf05.hostedemail.com: domain of mkoutny@suse.com designates 209.85.221.41 as permitted sender) smtp.mailfrom=mkoutny@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744390673; 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=04xvq7rYUEoUgFpD/ewNZ0HJkNgz6MW/nJUoaxZ4pGA=; b=cYCdmMQpIo/Q3HJmWKvQsDKkDrts19SVQKSb7dPzm7oi3I08HmPsrq/wK63hEDMHyzmlQk Gfh26OZWVxTNVWocD/ICQRDcgK8c54i7iYAFekwmNJCVQMxTHrWDQ2Sxjx9W97VIL0gJBZ GnUnfWMQX6AX/s7xg0KSXPkWJi3QfaY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744390673; a=rsa-sha256; cv=none; b=KpQWLXyY9Asq0Loyzqa32uuXQz1u2SBfHtBsGL9VDUOYJeW9NcmvRh3oSfWEdnHg9wL8RO SeQ3OJ34VMiA/E1hbZI9y60Q/u/Xdn9nX3kIK2hAwHGZFsPsBsGxkIAErB0TDrnuM53BQr LfkypXVmWpLATUnVyDUyDS2jjBwXCdo= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=Xv1VgzhL; spf=pass (imf05.hostedemail.com: domain of mkoutny@suse.com designates 209.85.221.41 as permitted sender) smtp.mailfrom=mkoutny@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-39ac9aea656so2134383f8f.3 for ; Fri, 11 Apr 2025 09:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1744390671; x=1744995471; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=04xvq7rYUEoUgFpD/ewNZ0HJkNgz6MW/nJUoaxZ4pGA=; b=Xv1VgzhLarcZpGN5jRiya26U35VPnu8z2et9GGKC5yUzATw7KRzzlPVK7N4Q3M71XR OeWQVJWKTqdz4UNy1F4geJJiMJh77a+uiqgKkho2ZDPXzyKqbe4NMwGxExw4os1xpBRK lPOWvs5D+qXa5VPcCMPporAx/dwVKU4u6qFMSvw2dBbdg+tvy0GxHAEoEYb5UIu58hiZ Bx0lUgggC0npuulOjCwxpG6V/KaONsKKVn4dso341c4eUds9tmhBoiRrh4VrP5NRACAS x6iilj3vN+tuZNwSJkKlCYbyPjYL2+ki2+8f9Y3nFixIKQRn+WbzHMy017HBSP5g5+4H K+oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744390671; x=1744995471; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=04xvq7rYUEoUgFpD/ewNZ0HJkNgz6MW/nJUoaxZ4pGA=; b=dsn7MUYCbuM3Ffy8lxEWrQa62dedkxb/YWZfXN2hgmT7CBrXE0uZPfzD1fpHowqaWH mr/3bebUiIfPnZ2dfjVswxLiGyebR7Y/0HAV45vpIGxNId6mNrL8XKAfh7knjXzzwEzm AvV9eOcB7tJDLfX1ImdI0VlgR78/GFinA5X9LcosBkqrONzK6+hIgWlalCS7SLtBZllZ xNB86Ne7hSi/7xSw1sYAPPHPvTMnRNq1cWSIvafD0zfm1TgB573rhyzpn7MBXMA09rQC 1jJH3/LWLIf654IP8fidrTiLpWJgvZPNBbthVoLdwAxeVo2CygRsPrzh4yA95rJVXOEa vejw== X-Forwarded-Encrypted: i=1; AJvYcCUeKKGp2WbxMgNN0vMW2uw92/qTJurWuzjmwxnh5ADMnmlqbsbUnDzBqdm9Ys+V9gkMVIAA/JcDFQ==@kvack.org X-Gm-Message-State: AOJu0YwwvzlBe2Kb+MDM5csq1A9ttuu4TxCuiMMMWz9na7a52nfyeTUQ s+7iwkd1VrkM3PGwxPkelKnnuMG6Pp25jnqP7G39XJx7+wG2qIH/kB/FCjCx1B8= X-Gm-Gg: ASbGnct0ELGylZDqk6aJpwmF5V+wpKGBReCCkP4aEq7h+jmjUnlY1nE3brZTXIiOS75 Z5HtonnehchEVGjwv3hu5u2kSc42+Rvep85/xLoqd+oQvSF+EorsbO4DZ5uSx/0Eeb01atp5Rox 1pDLlfgO5R35luMS5494DXzHlrd1YjY/4ZCdr1t5vIRV38j3khDd7O2PIQHsSjXeklrsiUf6v+H 6v48LKEi2WRuHs96/V7kPXohkyxSohVpSvpmtBpe/iUnhvS0hjmWgc9S8fOqrxd3Ye6XYlPTly5 +NT2yAccQEsv9anMa2iYrttk1v0CLG7+Ye0lfAP+cmg= X-Google-Smtp-Source: AGHT+IErI8KPwmdEuvWBk3FlgHVGYN+RcWvJM0a6rOwTi5daYDu+ij9vivNIziwzw8Zo71ai7Dk1fg== X-Received: by 2002:a05:6000:1a8a:b0:39a:d20b:5c14 with SMTP id ffacd0b85a97d-39eaaed2122mr3057697f8f.36.1744390671095; Fri, 11 Apr 2025 09:57:51 -0700 (PDT) Received: from blackdock.suse.cz ([193.86.92.181]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-39eaf445315sm2533527f8f.82.2025.04.11.09.57.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Apr 2025 09:57:50 -0700 (PDT) Date: Fri, 11 Apr 2025 18:57:48 +0200 From: Michal =?utf-8?Q?Koutn=C3=BD?= To: jingxiang zeng , Zhongkun He Cc: Shakeel Butt , Johannes Weiner , 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: [External] 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> <4lygax4lgpkkmtmpxif6psl7broial2h74lel37faelc3dlsx3@s56hfvqiazgc> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kvvrqpgkexpz34pw" Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: D5B4710000B X-Stat-Signature: yyw4keedzuic6535tp151srir44o6f9e X-HE-Tag: 1744390672-4392 X-HE-Meta: U2FsdGVkX1/mfZr2WPHNDSSnjTdR1C5CF8xDNYsPbhMWtlpCfui0UciF6cTMD2TU1CS0nwSWQL9T97Nv1yElbhhOwrFu2pIDyVxbqAdBxMDbCYrIj8zL02HbLTG3WMOd30kN1NEE/R9ySKLY+C0PgimdARLtNzEtOjHWs2mJGtZEqyk1Jf0LGlcSoNUvezoK6/eoFNTFvAu3g79pFv8U7SY0FGAWT8rlgVvcyhcysgkUf4TDUgE/oAaMo3m/CNOQstppKgluHdzbBPcgrNtYLHrM/0r4Uic5M0IjqC9uC8zRlrXJQ8kJtfDtOVp1CAqNj2B5XBXmWCPiiNtBrgPAG3qIglSgQcbqpBahBPTcfpRhH13kpMKvE80egQBpnwz+tKkDkGUSzGFRcvmSvs6e6JiyZY3FxEodCvaaHdWcJGYQDYsuSi2DpCWqhNGX4lQklRI3LVeb6kDW2fKTM4uvNZYnw0T6LIF5boQt5UtM4VqwPKW6DRBAtZRezuLU46G04+Kdz1uaJrn1gtKpem6IGtBvxohbT0K0mg69SuKLY2L7jJMtJ8OP+xjQJLORif29yeCUV4PtYSZ0wGmcycyJQDIwViXxCBK/4qpdUI4sBzMushSdqnGHk85Eh4PF5eGYGILbdXz7zdxT0rHmhcmjURg5BOWYZCuS6PyA7Lx4oM9ZPzR652p8KKxr+KKkj0m6JAy0ZcovN56oUUTIGc21cyucFnw9UGXXVIX6ooJr+1KVWegCvzY7tU1Dq8YPO+snK1iH4L7VFUA2ntylynCqXVsmr1QtlAw+KqG5q66jBV2Cv9xWdTld9EmTMbI0eya9Twt8hmKtsVjQZ1TFGCBtc/G4uZ5SdQzGbp7NCvgZfU8PUF1fN+FDWlI23NjXXQV5Mg7S2SJPivlx5xRl0PM7H776RQaV8+ojIacECv7hxQQZgf8Sd7eUiBmZe28nOpB+ZkxI5jHyicWACesoP3I 2JvC8bHM lZawEQEDkMHZ3NusFm5cHoHpfz/3biNTXgjYN+SmruLm6Pr3p9/EgbzA0mqbrAb+e1vN50HLKZUP8FHaTeUpsSkniTcRbiblng+xKMZI8n2yh7bxDb3Tmu0OPJ2sgQFXQvB3D6GK1p5ika2KqeRpYz1bysb5cKOidIh2MdnOErzIIO/vdUNDRiKIc7BTcJg5zYIexdijRWPYBYEdqWIkLd5grb3yXwOkWtdbVdUVj0O7vswoOoWOex7Cw80N7flKe0jIBvCqEfCqpoibWheqU44UpQux+1hS9W4tcUpn5BXm+xdyvpXaZrVbrPXCqhAbK/WuZ6pIRwo3gMDrwvR6pDlVth/yhZtNTb/lrZfGA5vxkEdro1j4kmgfHRBH45UYu4T2Co0A5Wpio9Pshezxq5XmaUIxiXZ3XjteG29vFwjSC2yragh9z3ZLb7S/+KQMsPt2SgPKCgHzbvA0E1jvfGWF8SU2vwj9nocqNPfyHlYpb9Hia7B6CAirZJR3lkjyjaPVs/psjI0OSLEqL5x1YP9ZtdVPbb20IKTtIQUffEKdvxTUVDVIMNJeGYQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --kvvrqpgkexpz34pw Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [External] Re: [RFC 2/5] memcontrol: add boot option to enable memsw account on dfl MIME-Version: 1.0 On Thu, Apr 03, 2025 at 05:16:45PM +0800, jingxiang zeng wrote: > > We encountered an issue, which is also a real use case. With memory off= loading, > > we can move some cold pages to swap. Suppose an application=E2=80=99s p= eak memory > > usage at certain times is 10GB, while at other times, it exists in a > > combination of > > memory and swap. If we set limits on memory or swap separately, it woul= d lack > > flexibility=E2=80=94sometimes it needs 1GB memory + 9GB swap, sometimes= 5GB > > memory + 5GB swap, or even 10GB memory + 0GB swap. Therefore, we strong= ly > > hope to use the mem+swap charging method in cgroupv2 App's peak need determines memory.max=3D10G. The apparent flexibility is dependency on how much competitors the app has. It can run 5GB memory + 5GB swap with some competition or 1GB memory + 9 GB with different competition (more memory demanding). If you want to prevent faulty app to eating up all of swap for itself (like it's possible with memsw), you may define some memory.swap.max. (There's no unique correspondence between this and original memsw value since the cost of mem<->swap is variable.) > Yes, in the container scenario, if swap is enabled on the server and > the customer's container requires 10GB of memory, we only need to set > memory.memsw.limit_in_bytes=3D10GB, and the kernel can automatically > swap out part of the business container's memory to swap according to > the server's memory pressure, and it can be fully guaranteed that the > customer's container will not use more memory because swap is enabled > on the server. This made me consider various causes of the pressure: - global pressure - it doesn't change memcg's total consuption (memsw.usage=3Dconst) - memsw limit does nothing - self-memcg pressure - new allocations against own limit and memsw.usage hits memsw.limit - memsw.limit prevents new allocations that would extend swap - achievable with memory.swap.max=3D0 - ancestral pressure=20 - when sibling needs to allocate but limit is on ancestor - similar to global pressure (memsw.usage=3Dconst), self memsw.limit does nothing - or there is no outer pressure but you want to prevent new allocations when something has been swapped out already - swapped out amount is a debt - memsw.limit behavior is suboptimal until the debt needs to be repaid - repay is when someone else needs the swap space The above is a free flow of thoughts but I'd condense such conversions: - memory.max :=3D memory.memsw.limit_in_bytes - memory.swap.max :=3D anything between 0 and memory.memsw.limit_in_bytes Did I fail to capture some mode where memsw limits were superior? Thanks, Michal --kvvrqpgkexpz34pw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQTd6mfF2PbEZnpdoAkt3Wney77BSQUCZ/lKCgAKCRAt3Wney77B Sd4XAQD1bRQA6yZDQoj/MJ+ik5mlhJTIQdWWOLsLZzeI3md67QD/V43upzY0A00m MglkEUF7IOFMdyMrZOaQ5CzGBLohuwE= =g4em -----END PGP SIGNATURE----- --kvvrqpgkexpz34pw--