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 46D5BC021B8 for ; Wed, 26 Feb 2025 21:13:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D8EA7280002; Wed, 26 Feb 2025 16:13:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D3D42280001; Wed, 26 Feb 2025 16:13:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C042E280002; Wed, 26 Feb 2025 16:13:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A3386280001 for ; Wed, 26 Feb 2025 16:13:37 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D1DED140B9C for ; Wed, 26 Feb 2025 21:13:36 +0000 (UTC) X-FDA: 83163347232.01.A2DFC65 Received: from out-188.mta0.migadu.com (out-188.mta0.migadu.com [91.218.175.188]) by imf25.hostedemail.com (Postfix) with ESMTP id F02DBA0011 for ; Wed, 26 Feb 2025 21:13:34 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="E6R/KFIV"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf25.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740604415; a=rsa-sha256; cv=none; b=BLnRY4QrImk7F99NGTIdxFNtrQDUCMehczGkJEoW1+CiuLgd8yEmvflkikV5l4ieafwwIM EzAcVT6/+g74bH4G1zrcF7ukZN2VVkRBmoJN1aBpn0Zo6kEKYDsRJ30ewcn/d4L/G7CvIa lz2Bzr7YUksC64+L9jy0eaq3VnBKMQw= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="E6R/KFIV"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf25.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740604415; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BWPw8dfW2CKCuC+NKpHNqPJSNvcldwRNktFZqPfqU2s=; b=cGHBJXpW8BuK/Yki4WucIZmmL34QTQiMRdlS1JktLIHpDTuaGg7tqC1firMjAMzlwQCwHj u3HBST78TS/wWrJgyB6oMw781rp5eOJbOwSD2cDDiuzRcgpSwgFdJimWdgs0eI3GwunhXo nlQtsvmfNNE8xLn7SVgr0yWN1JKhpQk= Date: Wed, 26 Feb 2025 13:13:28 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1740604412; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BWPw8dfW2CKCuC+NKpHNqPJSNvcldwRNktFZqPfqU2s=; b=E6R/KFIV4Rp5HH5CLpsx7TNcbvC7wNUl3YqA/sjctG1VLvuVcfn9qd2ixbFxmEpZPXEaXE S0Rx7kEcq1J7/dIxW5JZgGHxQDfHUS1v1z8Y5TAVHbnqUFMBdW5gjFF2R+/9unLJOw6mnV gaNEVfOIwZGOlLShLf5Or1J9AvUVdTE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Michal =?utf-8?Q?Koutn=C3=BD?= Cc: Roman Gushchin , Johannes Weiner , "T.J. Mercier" , Tejun Heo , Michal Hocko , Muchun Song , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Meta kernel team Subject: Re: [PATCH] memcg: add hierarchical effective limits for v2 Message-ID: References: <20250205222029.2979048-1-shakeel.butt@linux.dev> <5jwdklebrnbym6c7ynd5y53t3wq453lg2iup6rj4yux5i72own@ay52cqthg3hy> <20250210225234.GB2484@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: F02DBA0011 X-Rspamd-Server: rspam12 X-Stat-Signature: wrw9ra3qmrasd859ey5es65ehueifanp X-HE-Tag: 1740604414-814560 X-HE-Meta: U2FsdGVkX1+sAb22s5O+IBfurxPgTvxVoU8PRPT0oLbFLkXmP/UHk3UqBUBT9DTVOqjv6FW6dgr2INygDVgSvhrHyMCc9E7S3GEQ4gPzBOTmVLb2Fq//bLvM+rd46x9ZENGAl0uolDONnKV8BkcFDDTXqcqMWJZ93wEWqmBURaXNx8I0r5vkLuyZEAKhYjdDxjb2siq2Bfs4/2GnblSrr5zetlsslgM132h2HorNcO+bB+Q9PlrXhZjc+jg4GUp+fAVFxSgcvGcRdba2ntuvTUhsJCyQCrAnp9JPOghQ2lmm71GGpTU2Z/E3JOo5ntaAD2d/GTxydi1PDRzed/pydcgJyvBvRl/kE1v00e3muZnCw6q8iANJIiM9Dk2LLZQ1uNhuSeljJA2pPbJbkYyjeQW4q2OCqaGP8S0N7pPnELiq2HZVmxN/FpsI7QeBuLg5RQCQqIRR0L7zqWU17j/0cNKAdkn6rSwmULjG+C/Y6Sr6D76dNnOD29ThXDwDzkQij+xxedmfYH6+GRc0JrTVy4bzqBuUz/RSP+hxelTBD9NPGFGzax8RcrIJJjo/ay73mO9B7ifiviXAGyE8+XUdkWSvbbxBd7U9WTA2olF5TdTKNAY+iL315NwYKh9RJpZ+rty+AErvybNgL2pg6TPUgFlfl89iRtqpl3AIlcuU9k9WUH6LDDYGiCeUfevZ+9F1XUhdIhGr3bgkJUb9l1lCw5OahkvI4o5kgJIyqQg+qppsp1u5vKLvHXjRPC9NZ/ilfTwVvjKRm4redxoZeof0+2nvdHPeX6XG0zZ3LfBPH+nhZcRf2Ztue7pRpcyoFuJU4ZYS5iFul8qTBo1L7KxrduCfEm9OLzRP7MTxH2lP8CST4PwUeTgyutXdsvXE2uz2tMR1aZ8hhKG7irpEUMpgozn/XQbfx4r2NxNGuriildrX92fLiXbWhoqpqsJPUtxcaAQb8bucIvP9lGUDBJB bf+i6YrH EJNvAUZiT7/5/qnOSiEkBJ5HL0GImCOTa3Vll+QNeq46nsHhsRq602oVx3uM3Bd2EvGOcy+yaR4siVSTo5aiLuRtUbA95DjWtpwjcp4x4ZCcRjntabNMfv4Zr7OJ1qa0WGOpwmWtkm2Gy8/GuG9NEoc0sYQareOoZv4zBoj7Fg/SqKAGvw0MRYX+1uuosfY6rCQQ/cOaQq1j81UudBV9BIHVWNaPdkfw43hSAFWr8YEUqAff/5hn4S1ve+P+yHK0Guq72/OPa76EpY2jjXLrGbJCm4/pp9523AEHEgu0/RXM7u+mVlDcwzgkDe2UhNssBZQ6eAH3MGtvqnTfvp1QGYFOzsiYiq3n9F3QD 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: Sorry for the late response. On Mon, Feb 17, 2025 at 06:57:46PM +0100, Michal Koutný wrote: > Hello. > [...] > > The most simple explanation is visibility. Workloads that used to run > > solo are being moved to a multi-tenant but non-overcommited environment > > and they need to know their capacity which they used to get from system > > metrics. > > > Now they have to get from cgroup limit files but usage of > > cgroup namespace limits those workloads to extract the needed > > information. > > I remember Shakeel said the limit may be set higher in the hierarchy for > container + siblings but then it's potentially overcommitted, no? > > I.e. namespace visibility alone is not the problem. The cgns root's > memory.max is the shared medium between host and guest through which the > memory allowance can be passed -- that actually sounds to me like > Johannes' option b). > > (Which leads me to an idea of memory.max.effective that'd only present > the value iff there's no sibling between tightest ancestor..self. If one > looks at nr_tasks, it's partial but correct memory available. Not that > useful due to the partiality.) > > Since I was originally fan of the idea, I'm not a strong opponent of > plain memory.max.effective, especially when Johannes considers the > option of kernel stepping back here and it may help some users. But I'd > like to see the original incarnations [2] somehow linked (and maybe > start only with memory.max as > that has some usecases). Yes, I can link [2] with more info added to the commit message. Johannes, do you want effective interface for low and min as well or for now just keep the current targeted interfaces? > > Thanks, > Michal > > [1] https://lore.kernel.org/all/ZcY7NmjkJMhGz8fP@host1.jankratochvil.net/ > [2] https://lore.kernel.org/all/20240606152232.20253-1-mkoutny@suse.com/