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 F025AC3DA49 for ; Thu, 25 Jul 2024 23:12:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F1B2D6B0093; Thu, 25 Jul 2024 19:12:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC9E96B0095; Thu, 25 Jul 2024 19:12:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB8946B0096; Thu, 25 Jul 2024 19:12:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BD7E56B0093 for ; Thu, 25 Jul 2024 19:12:27 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 355AD140BAF for ; Thu, 25 Jul 2024 23:12:27 +0000 (UTC) X-FDA: 82379825934.09.5E383CF Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by imf12.hostedemail.com (Postfix) with ESMTP id 5A15340017 for ; Thu, 25 Jul 2024 23:12:25 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="PNcbxJe/"; spf=pass (imf12.hostedemail.com: domain of tjmercier@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=tjmercier@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721949120; a=rsa-sha256; cv=none; b=ZLIATF4aiMCIzYfToABp+uGX1z/6bIoO0HE9IvmzCo4RB8vL/Fw1234gysvZe1v4chMt5B y90SVRihCRYsDdQniuc7RzC4dcqON+S7b9aK5zIPX1lBagbnIkJ8yt+KduugA/m1AjUjTD yRUePoCykMIeBKo0YsDj/xAT5TBoxLs= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="PNcbxJe/"; spf=pass (imf12.hostedemail.com: domain of tjmercier@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=tjmercier@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721949120; 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=V3d1zGC521b6j6WMF79KL4j8jgavX6XjnXIm0tZCyjk=; b=dEYtdAKcc2UL/2T4bqaslCNYDyXgXSEbBcp3C1GTLYMD/7o3jbqzYbFy9YtaoJZKfXz7G7 eo38cfZRiOzXOc7Of21oufv/KWgDgdigCvPUSDizY3RKfZGGbtMQO6PcxJ7uigthwZHBwm p7VMJaITD/uRuYQKjjdi7uvIVls9w4Y= Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-dfe43dca3bfso1493713276.0 for ; Thu, 25 Jul 2024 16:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1721949144; x=1722553944; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=V3d1zGC521b6j6WMF79KL4j8jgavX6XjnXIm0tZCyjk=; b=PNcbxJe/YJIqI5LyoiFGD2jGF5rk91+waNekdayHOWA9BO23LbaQCdTuNohwgFK/gF X8cx4DxZGNi4goTELPt8p3COshnH+TPsBzMc33JRygC1Jby/9xC0Sv2TNfEIZYdmLdDZ NnErkSxYgAH3/MSFbdPmbkG7RvznQf+CsTEv7kE8JT8NBAtY02Fx7/IKNBshASVBycll iumddV0ZLessX3tzhsij1/dxl8EqHk1aVWEA/5Lo8lAetcvdGcx4tlh6jI/xCuNKCCb1 T+lj8soblXgzNvUGxMbZ6rIQt8Fs8ctQnVXQhgX+G4Z5ILGd1riPGQ9YuFv91XpFmMVz R6Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721949144; x=1722553944; h=content-transfer-encoding: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=V3d1zGC521b6j6WMF79KL4j8jgavX6XjnXIm0tZCyjk=; b=N4sgWO4zYcSIY7OYNh90O4ajABK7ttEs5cEMA6BP0cMfJpqMFi27Q52ouvrqmCskjD qNDXxn4SKqYRl9VuS1j+u7zLhvii1gK1dauhpewbW8Mx+/XPekVby31ey7k3IVQh3WDo nMsq96SdzeAheK1YPD9wVtLsL5GyMMN5hzsA0cTAkqfYJbYVHgYBiYdISabxjRobb6Rs 46OVhsczXKb5hbOw3sniRBtEzB8vDWgm656rSZZkZKL58dz8eTVo9a1sC9MZsgIYAw/L 2SqPsnPYuRTl9A8O8FHwar1usal3FvAxztd7x8pOzcsEdRQc5uPsS/EN8iP10uc0rFJe +3Ig== X-Forwarded-Encrypted: i=1; AJvYcCWbDQoBNItz3CYV62RxikA0yT0vLS2wVtdoNq/I51Esc23WkaLUWBdbUndZSqgn5uPuhy8mvufoHIF0DHnp1xGeNXk= X-Gm-Message-State: AOJu0YwP4XrCa4mv9Y27UJF80cLHc9SIU5J/d/jWUVsxV4ad7x4coODk JxaK5RQE+fCEYLdCywdYR3ln1qxlDK6qlP+ZCIkWnLu0Clr2Zawx8hZxt6IE3z59V6TzUQqJBuH ZvK0k0+4Vkxw9danJYsb99q/TqrbcKfenkrkp X-Google-Smtp-Source: AGHT+IETY78vyhD6DEhT9etUSc8N43LepRmktceChLoKqRE+NzzWbiEyqOzvL9PRN7JfjPX50EG5OzRZoObQNo3ZoU8= X-Received: by 2002:a05:6902:1ac9:b0:e03:4501:6102 with SMTP id 3f1490d57ef6-e0b231f402cmr5256018276.46.1721949144110; Thu, 25 Jul 2024 16:12:24 -0700 (PDT) MIME-Version: 1.0 References: <20240722225306.1494878-1-shakeel.butt@linux.dev> In-Reply-To: <20240722225306.1494878-1-shakeel.butt@linux.dev> From: "T.J. Mercier" Date: Thu, 25 Jul 2024 16:12:12 -0700 Message-ID: Subject: Re: [RFC PATCH] memcg: expose children memory usage for root To: Shakeel Butt Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Greg Thelen , Facebook Kernel Team , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: du3jfbp5bmnczdqmkbw7fs3rnfafpt4i X-Rspamd-Queue-Id: 5A15340017 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1721949145-850341 X-HE-Meta: U2FsdGVkX1+Yy8Wxk2s/U8x+tQqzCKj6zlyhXlq2I7oly/j1+WNmo2UtSU7Z5Qmt1HYwNFNDJ7nIS4dS4yLQ78NWmCEQPeUJ7mc1oso6KwfIDEVem+DufhWrXypO+u1m2IIAKevUZn9CcI93mo17XrG7/n/czAU02aVwAEmaZpJ4qGasPxfAonc7+QudIS58dWa/8gRfQDONDpll2KHmpF75aICqxLOHMME/8cr0cE/IQdc+Vjz74dumSmoE5XP1WT35bJMYMHu01DTXXWBes9wHdK6CLg/8Z/zNCo8IwVppxILyU3vsgzk8nsXIYPPS6jaV/bFxOmGB9isN8cuRFt/n8K6ttyuFEPMZkCTgGGVn8G4+y/tju9qvBix0n4rjjvI8ez3aZyLywg7nbgai83HQS3bHrAtxH2/JmuTO6D2yss6U2Bev8jsiSMt3Dw3Qky+sBSRZeVbviCGDi+wXAUteLOQj93mjDMmzbC16nnNokC4m+6h7h3mdsehtTKXmGQf1C2M3WZG0DFdO75euValuweondf/bJ8RoY/Sy6vPnDRC4dcGEN0Os4u2qUl1M3rcYxDC8EinjGXoF9AC+9f6yMopayJWjNFvrLeVUFS+/DETKFUukyVZiHUjJiXB9nda/cGbrAAwm+Bu3GdYG+FZc5pVmxmQ7ilWawoFsW5kpEdBJvsblahKDQGJeI0gwW8MIo3582sTdC/4lBPoZe6RdOvMCBFkrYiZ1QW6ASD6Zfbpwc4VPvRH1zmxIoIckkMLAAZxvkyEeLXpE+dRh6bAyDCPzvpJHDBgKB+NkF8CnvIrsNCbPofwBJ13brXgGulQIrnET9xnPCrOxh8Wt2QbczyOzF/FzPw2JTcw/5Y+1m6WhFntVpVdbmDO6zak87MrQXSM0S/zzT0e2LubhTBVvFXsAt8TmG4xLXMqOvk6r6dj2GageavHbLNp12AycEuwb42m3l0/HDv5d6Ep O87K6EWv 6Pg4/V9R/PTSAK0OhjNAFPGPhyYF/XxQMTr46vs7sOE8xExdOxsJUiraoxS4l8ZluAMw5AaPdmT88tWYlBpWpQVDpLu3ywJ09DxV0ET9DKPrjvjvLqu0GoBqI3WD+kmoQbXuEQXpaI1X7XBM8ZIE2uIcX64ntZf63UgUldwMUp6ex6rE= 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 Mon, Jul 22, 2024 at 3:53=E2=80=AFPM Shakeel Butt wrote: > > Linux kernel does not expose memory.current on the root memcg and there > are applications which have to traverse all the top level memcgs to > calculate the total memory charged in the system. This is more expensive > (directory traversal and multiple open and reads) and is racy on a busy > machine. As the kernel already have the needed information i.e. root's > memory.current, why not expose that? > > However root's memory.current will have a different semantics than the > non-root's memory.current as the kernel skips the charging for root, so > maybe it is better to have a different named interface for the root. > Something like memory.children_usage only for root memcg. > > Now there is still a question that why the kernel does not expose > memory.current for the root. The historical reason was that the memcg > charging was expensice and to provide the users to bypass the memcg > charging by letting them run in the root. However do we still want to > have this exception today? What is stopping us to start charging the > root memcg as well. Of course the root will not have limits but the > allocations will go through memcg charging and then the memory.current > of root and non-root will have the same semantics. > > This is an RFC to start a discussion on memcg charging for root. Hi Shakeel, Since the root already has a page_counter I'm not opposed to this new file as it doesn't increase the page_counter depth for children. However I don't currently have any use-cases for it that wouldn't be met by memory.stat in the root. As far as charging, I've only ever seen kthreads and init in the root. You have workloads that run there? Best, T.J. > Signed-off-by: Shakeel Butt > --- > Documentation/admin-guide/cgroup-v2.rst | 6 ++++++ > mm/memcontrol.c | 5 +++++ > 2 files changed, 11 insertions(+) > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admi= n-guide/cgroup-v2.rst > index 6c6075ed4aa5..e4afc05fd8ea 100644 > --- a/Documentation/admin-guide/cgroup-v2.rst > +++ b/Documentation/admin-guide/cgroup-v2.rst > @@ -1220,6 +1220,12 @@ PAGE_SIZE multiple when read back. > The total amount of memory currently being used by the cgroup > and its descendants. > > + memory.children_usage > + A read-only single value file which exists only on root cgroup. > + > + The total amount of memory currently being used by the > + descendants of the root cgroup. > + > memory.min > A read-write single value file which exists on non-root > cgroups. The default is "0". > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 960371788687..eba8cf76d3d3 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -4304,6 +4304,11 @@ static struct cftype memory_files[] =3D { > .flags =3D CFTYPE_NOT_ON_ROOT, > .read_u64 =3D memory_current_read, > }, > + { > + .name =3D "children_usage", > + .flags =3D CFTYPE_ONLY_ON_ROOT, > + .read_u64 =3D memory_current_read, > + }, > { > .name =3D "peak", > .flags =3D CFTYPE_NOT_ON_ROOT, > -- > 2.43.0 > >