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 8512CC02194 for ; Thu, 6 Feb 2025 19:09:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C159A280005; Thu, 6 Feb 2025 14:09:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BBE9D280004; Thu, 6 Feb 2025 14:09:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A82DD280005; Thu, 6 Feb 2025 14:09:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 7C150280004 for ; Thu, 6 Feb 2025 14:09:16 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 27F2FB2756 for ; Thu, 6 Feb 2025 19:09:16 +0000 (UTC) X-FDA: 83090457912.30.E90AF46 Received: from out-181.mta1.migadu.com (out-181.mta1.migadu.com [95.215.58.181]) by imf23.hostedemail.com (Postfix) with ESMTP id 21FB1140019 for ; Thu, 6 Feb 2025 19:09:13 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=KkNqJ9xm; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf23.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.181 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738868954; a=rsa-sha256; cv=none; b=Je3D1WFW/09fKomhZz43nB+xB5MQKKv7pJ7l9AGPx4DCMb5x77sYKMeI/iXOCh5zQ2cSOw qOEdW3TVQL9reZTn+YbU0bW7gWz6aDUx1GPUj6bpi3jXN9kxm7v0nOD7VHKyGLJ6j4+zx8 RVSbro6jtvRZbYH6fiXXZfF+sdXfwXc= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=KkNqJ9xm; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf23.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.181 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=1738868954; 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=QDtLyV5ZW85qPe+cCxXuWO18ZWNEpGaNQrn9/hMmsxQ=; b=wV7KMKdivh0808m663KHF3f3lz38Dxk6ZzP+MsK76oUSjTcz4DAP84eQPdCdeCuONPnCmU 8uQsRHSC7k2AJKvSFh4PWFOKIg/RWQFelJZmzMTgY6/VTLxISGObS/d7Dn8So+cXIvOZ7Z NQhs1USURTJX35MWgzsLzPSzX5ULp1s= Date: Thu, 6 Feb 2025 11:09:05 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1738868952; 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=QDtLyV5ZW85qPe+cCxXuWO18ZWNEpGaNQrn9/hMmsxQ=; b=KkNqJ9xmV++MrcFAiUc8EGYB4ZnytHs8ecwkf4YC4ilwwWnsq4NrA63Sx0PoxboEPj1CY3 Ps73IBskQrVS/oYI5pKoaBpYqUtKzqKzQMCw/nb/Tba1BDDMGNI3DwbjL+l7W5YgOYIx7P 5ho9jlfXidPjPsFL5ME7uXsSmzVBYi0= 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: Tejun Heo , Johannes Weiner , Michal Hocko , Roman Gushchin , 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> 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: 21FB1140019 X-Rspamd-Server: rspam12 X-Stat-Signature: xgzwb5n19jihrkuh711r33eq36zpwk3b X-HE-Tag: 1738868953-9062 X-HE-Meta: U2FsdGVkX19VTdD62uJtB9jDVrxU0LqpUpcHvPJoJPAAxv63vEpGIh8eJ36F7qQuAUiCpZh3G6gcpldFKUriinYeUPYyXUNkUBT1C5n5VJeN0To4DWDjTVASC5345GlDNDGqR3rVLa03NtjwA7fZ5Q7NhFXGj4qehF4ZoOXD8MQGQ5kTGNTNjnWjVOL4w1XB75kIZIk8to5wD9QZUIT3j2VpW2a5Ubz5HXWZEhMmCxOhxh2nKoCfQe5xuGxXKT6s64eqfE0IuK38tyG1S19HVkTpVsQqwKE7X5xXphxGcAHjHVWBaOBCZEoRbvz+6rmPE9RE9OpssQ0QoiDXqLycsi9eTxHEZFiUs14ZnMewZv1v9tvsuyfApvyBRah4O8ELVaMAZYo3dWTdX4SFyWauS4fDpTSeOT6HoG7pwUU0M85Ip7BmxsAiZkgoAms3Lfi6CoKEeeiqh21Kh1GJ9nNl0ZlUofo8HEAD1nDxrkKt8Tsi5JbwFvuhtAuVVv2WZuD63piwwSJHLoz0wGXMuy7JyrCxKpZorSwHVzubTxEeuX1DfDRiZ5JzAPga6Fza98Z7IRNJ5Jhp8JQyPnrs8L8/2wSgvW6YYoYI7GP8Di++UR6d7wuMA2mzubeE03AQ1YqridQ75wmLykUaUuHVOenJnm1Zh8UUYSVxzKfrQYEz+x0sVjPRtT29YRRZCGB89mVRO/liwvuDFMdH4ximamQHH9Dgx8LtH+XuF0dHDVYRBl5ITT5RiWUEUjgi1a4ezjneV5GzclOkr6t2cgUzlLFTfp1z+37lfKc20ZqtIOOBVgHD7AUSi+A3UIJKP4GSf/5dd55TE83xEAfWRhu/3mNLK7dQbznTPwHt3k+ITMW13W3fU698BEIGpVKbVjlFjOckqf1KhI+3B4DfwBMwQOcQnjTpU/cp4o1ZCdSJG7p84SqcxafA7XWvhvy7kiOhknkKCBsdYjhPP3wqZz7vuA0 Rwf4hx2y 3kgb/ELU03fLH/rQCWyO4/5+sENXpi1ddS3zbn03O6FEDL2Lrffb9MqsTg88K4rB/n2nO7UCiOrrLZTP4S9LMibDaFknhdvairxXcwoeilAeOyfSPLeXFDML2zxf8r9nHu+Y38roNCNGcRrTWhSewyOCaIvqrwtOURgmojfZ2wml6tFxCwH4Qz+H0cZHDVxEHzq7mzs9hDMPF+K8= 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, Feb 06, 2025 at 04:57:39PM +0100, Michal Koutný wrote: > Hello Shakeel. > > On Wed, Feb 05, 2025 at 02:20:29PM -0800, Shakeel Butt wrote: > > Memcg-v1 exposes hierarchical_[memory|memsw]_limit counters in its > > memory.stat file which applications can use to get their effective limit > > which is the minimum of limits of itself and all of its ancestors. > > I was fan of equal idea too [1]. The referenced series also tackles > change notifications (to make this complete for apps that really want to > scale based on the actual limit). I ceased to like it when I realized > there can be hierarchies when the effective value cannot be effectively > :) determined [2]. > > > This is pretty useful in environments where cgroup namespace is used > > and the application does not have access to the full view of the > > cgroup hierarchy. Let's expose effective limits for memcg v2 as well. > > Also, the case for this exposition was never strongly built. > Why isn't PSI enough in your case? > Hi Michal, Oh I totally forgot about your series. In my use-case, it is not about dynamically knowning how much they can expand and adjust themselves but rather knowing statically upfront what resources they have been given. More concretely, these are workloads which used to completely occupy a single machine, though within containers but without limits. These workloads used to look at machine level metrics at startup on how much resources are available. Now these workloads are being moved to multi-tenant environment but still the machine is partitioned statically between the workloads. So, these workloads need to know upfront how much resources are allocated to them upfront and the way the cgroup hierarchy is setup, that information is a bit above the tree. I hope this clarifies the motivation behind this change i.e. the target is not dynamic load balancing but rather upfront static knowledge. thanks, Shakeel