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 3406FC3DA49 for ; Thu, 25 Jul 2024 23:21:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92D366B0093; Thu, 25 Jul 2024 19:21:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DD336B0095; Thu, 25 Jul 2024 19:21:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A5286B0096; Thu, 25 Jul 2024 19:21:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 5CDA36B0093 for ; Thu, 25 Jul 2024 19:21:26 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BD83A16141D for ; Thu, 25 Jul 2024 23:21:25 +0000 (UTC) X-FDA: 82379848530.22.3214494 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by imf03.hostedemail.com (Postfix) with ESMTP id D83CF20030 for ; Thu, 25 Jul 2024 23:21:23 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=KminJRZR; spf=pass (imf03.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721949659; a=rsa-sha256; cv=none; b=rhNghB6YC+Vomm7ZGAyjin2lJgv8/eVJdPcHEI01b9Z0oYkO/VSOy1/z16XS2qzM5lYpYA MbBM8Tsqk7chkwpo9SI0B9oZoA9ynl0AUCoe4hk1CTpKmFsdHDQYmMo4DYmTj0bCW5JZoJ qos1acXFK7RIP+yfUBq6HnDRoiK88no= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=KminJRZR; spf=pass (imf03.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=yosryahmed@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=1721949659; 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=9BhWFqkULj+AvRbdCNR9XG39O/J74nwNfGpIydF1LCg=; b=bSuDdRzPGy6NPIHB0CmEeZHx744JddmojPzwzfh5fYn9u0jeD7XIyNh/copj1uOd3VutFH jM6frUELan4gNAYQSJNa0O6yxAzXKupgErw7/pjjbN0mjLStz9G8NUBrGv+azWeqSs50Sd 99DuDYdMRuama1D837tZpKweNmHjfAU= Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-a7b2dbd81e3so140851366b.1 for ; Thu, 25 Jul 2024 16:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1721949682; x=1722554482; 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=9BhWFqkULj+AvRbdCNR9XG39O/J74nwNfGpIydF1LCg=; b=KminJRZRUNbLcz1ThPJPvMXfanAR8894bWwCV2MtMJB9hoBfWNzxkW3IMgSm+B7/OL LA7SambSjJZRfZNJDm2qdwy/z8qslIFQFKvu7v96Y4iXKsH77dTl7R5OVm9V3FZbusV8 OWTJF4T4FWQDBuUilaGc4UAeDGs8DzRQannO4LP5Vv5NzobUWATDMYfarJ9I1DgemJIx bLnwlHNVLwQsWVIRhIpTWeNJxph+JArtNBAvbsMCOFtZ1Oc+cjTy5pI8DZJyrMhv0n98 B/j3mN2nTKAkxMwn8eGK6QLvxX0iBX7iOtpFRKBrH7iQ5Cs7ld8WSdzFeFGcSsMANDBO aSVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721949682; x=1722554482; 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=9BhWFqkULj+AvRbdCNR9XG39O/J74nwNfGpIydF1LCg=; b=vMMi1LKmpIKX3/CcoUy+1PdHxPeUTsg07HucLQiY8wqLkSJvJ2ySu5rXU3HTF/QEi9 M17KU685+TlcP2Gv44H1P4J0O/osG85Q2AN2dEpSV6AxHgwxi+blg9tmRG/yg++0jZLQ 4zyZ6Y/MSvcTQgkwQNDpLjSSJOa7Do3chT9V6lpWhuTC80sH0CjfcHLSvujHhIzvQOo3 SOQVpTCI4ZYJPRO9jOBXvpiQ7WPRh/lIRghbhIDVyB8zzdP+xgCZan0YlfzDokgcXsZX jLbmk3fUL8dUlI6gECEpmLCA29zfGwb1blLi5ZkgeL1MFeaY5m3TmMloAd+0UtFUF0B4 qgFQ== X-Forwarded-Encrypted: i=1; AJvYcCXyDk2rvY9oM61BMuPmg7MN7anpfwY7GouAE79vy7aPLGPBOjfSbJHP5bdKyF4S0JuXR1O9PfnQLDjwuUJ5/BRC9Rk= X-Gm-Message-State: AOJu0Yz343Nu+5l9y2CFgdlrj82sQoT+1kmq3eB3PEqAi8wha8irO2Lb LmJxv0SlQvqKTL0iNNLQfZthMdFfvTZaf1xm79MJHxcbVmWK7rArUJN0cM4mLy/mpsv+s14kA9h 0VbW5KfvvjrVBgOALJQ+cujeahXWrK7p3vJ/L X-Google-Smtp-Source: AGHT+IHJ59e3RjfpIjsYfqW7mSWdBpnmRV6+dg8CCj0u3/kAEp8Crps2xN4z3/VbgDQB02FDUaGMQUFTjFWq19hvltU= X-Received: by 2002:a17:907:3f1e:b0:a72:4444:79bb with SMTP id a640c23a62f3a-a7ac5087ca2mr386817766b.59.1721949681571; Thu, 25 Jul 2024 16:21:21 -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: Yosry Ahmed Date: Thu, 25 Jul 2024 16:20:45 -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: epjzci558ysj3i6wat89ath1judn1w6w X-Rspamd-Queue-Id: D83CF20030 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1721949683-418286 X-HE-Meta: U2FsdGVkX19hankRPaumXlopXl83tfUzqMV2njvBTa01LQYkdpDHgdLqFFbb0hHahAwm8Oi+KEKBEkJf83nJkn51WT2coYjaLHSb2eFHy7cWxbvKMy4tZc1uRQ0adqf6a3+ju6TeOwClY8iPfIjjZ/PG7HvgZL8T1/WdivKhf43QnFl+cWUf9j/ViPdSIDVH8RP1HxqyuMOoygEXul3US3F41M0kXBCZPNov2waf5iVEzX7OxQ5m00zm8oVJ/YmkAO3Srs8hox+BE9mk08dfUcLd8ccn/jwr/UX1nlObO6ZKHfSBCK5rdknfW1a3ZP6nSv01cbsOMsj2owrKimoNv1SkXj0xpaXWFT5lR4pOvqOty061kf0snWUzEeS4fOF/XIUsAeL9R0lUbHDxsPYJlOOlR2jqmtsdF0mJWcYav/L+teFjxZsP7mGc/fnIVeml2xqaCJv1mMWN3cYum40HhXVcI/0xdiIFjMS/5FrlG15llUfgvPGZj4eyvuT4RGEcsPB6sZ+WV3/MeK2f9bGZB6oP9rgu110vg3ZUYBCQI2U6ZS5aiGTEA5aaCFa0y66QozLjdvAoeIzirrNo0Xn2uXdbXNeFeTHiITMZ53GpFuTcTDj7SH+/YArjdivd6pfkYxJy1oDsT7kpZsICGs1Jj9UP2UPthy6PBJi/A5fXqgiGxPE5H3BSUvEZ7MZ0gFVrYkO98W71vfr2CMRH2B5zkYZOqflCiCA1dlUoKhdc6QgUrOtW2QrNY5AhiM4efPfzAMe3n9RZjM21skQzV7ucQwIFlw5qebUUzkXuNA5LPsLtqsKfsQhTs9TGgu8vJRgS7aLcSpkjY3UOPAkqJVb0j7+0KkzC4muHifUvFtGxpJCBsPmNHwcMFTejKm8Wkmk+BDHk3gr1J9VHAZv/c+GIrOtniR9jhuSrbr4xgHGUkhKfgmsSDbrZFHin0TfvuW8tbJX0RSzOaqFPIuQZTQp Ub3MmoNI /mET+xj/n6PwReMEzYjiY82i7N9jBKlgharoNv2stnfO7+23W8GPctO38EDj75fOu8CyoP2oOUouHzgdCwSPoEKVFfPpMq444MCXV1QIMMYAmYylp2iITjRwaQ7voIhDyPszQq5Nrq2iny6/pQoPR7M5l1h1g1Jo1k4WfRVn/tOZr9to= 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. I vaguely remember when running some netperf tests (tcp_rr?) in a cgroup that the performance decreases considerably with every level down the hierarchy. I am assuming that charging was a part of the reason. If that's the case, charging the root will be similar to moving all workloads one level down the hierarchy in terms of charging overhead. > > 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 > >