From: Joshua Hahn <joshua.hahnjy@gmail.com>
To: David Rientjes <rientjes@google.com>
Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, nphamcs@gmail.com,
shakeel.butt@linux.dev, roman.gushchin@linux.dev,
muchun.song@linux.dev, chris@chrisdown.name, tj@kernel.org,
lizefan.x@bytedance.com, mkoutny@suse.com, corbet@lwn.net,
lnyng@meta.com, cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH v4 1/1] memcg/hugetlb: Add hugeTLB counters to memcg
Date: Mon, 11 Nov 2024 10:58:32 -0500 [thread overview]
Message-ID: <CAN+CAwPSCiAuyO2o7z20NmVUeAUHsNQacV1JvdoLeyNB4LADsw@mail.gmail.com> (raw)
In-Reply-To: <72688d81-24db-70ba-e260-bd5c74066d27@google.com>
On Sat, Nov 9, 2024 at 9:19 PM David Rientjes <rientjes@google.com> wrote:
>
> On Fri, 1 Nov 2024, Joshua Hahn wrote:
>
> > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
> > index 69af2173555f..bd7e81c2aa2b 100644
> > --- a/Documentation/admin-guide/cgroup-v2.rst
> > +++ b/Documentation/admin-guide/cgroup-v2.rst
> > @@ -1646,6 +1646,11 @@ The following nested keys are defined.
> > pgdemote_khugepaged
> > Number of pages demoted by khugepaged.
> >
> > + hugetlb
> > + Amount of memory used by hugetlb pages. This metric only shows
> > + up if hugetlb usage is accounted for in memory.current (i.e.
> > + cgroup is mounted with the memory_hugetlb_accounting option).
> > +
> > memory.numa_stat
> > A read-only nested-keyed file which exists on non-root cgroups.
> >
>
> Definitely makes sense to include this.
>
> Any reason to not account different hugetlb page sizes separately in this
> stat, however? IOW, should there be separate hugetlb_2048kB and
> hugetlb_1048576kB stats on x86?
Hello David, Thank you for reviewing my patch!
The reason that I opted not to include a breakdown of each hugetlb
size in memory.stat is only because I wanted to keep the addition that
this patch makes as minimal as possible, while still addressing
the goal of bridging the gap between memory.stat and memory.current.
Users who are curious about this breakdown can see how much memory
is used by each hugetlb size by enabling the hugetlb controller as well.
It's true that this is the case as well for total hugeltb usage, but
I felt that not including hugetlb memory usage in memory.stat when it
is accounted by memory.current would cause confusion for the users
not being able to see that memory.current = sum of memory.stat. On the
other hand, seeing the breakdown of how much each hugetlb size felt more
like an optimization, and not a solution that bridges a confusion.
I have not had a scenario where I had to look at the breakdown of the
hugetlb sizes (without the hugetlb controller), or a scenario where not
knowing this causes some sort of confusion. If others have had this
problem, I would love to hear about it, and perhaps work on a solution
that can address this point as well!
I hope you have a great day!
Joshua
next prev parent reply other threads:[~2024-11-11 15:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-01 20:44 Joshua Hahn
2024-11-10 2:19 ` David Rientjes
2024-11-11 15:58 ` Joshua Hahn [this message]
2024-11-11 17:41 ` David Rientjes
2024-11-13 22:42 ` David Rientjes
2024-11-14 1:08 ` Nhat Pham
2024-11-14 5:26 ` Johannes Weiner
2024-11-14 10:33 ` Michal Hocko
2024-11-14 16:36 ` Roman Gushchin
2024-11-17 3:34 ` David Rientjes
2024-11-14 16:42 ` Joshua Hahn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAN+CAwPSCiAuyO2o7z20NmVUeAUHsNQacV1JvdoLeyNB4LADsw@mail.gmail.com \
--to=joshua.hahnjy@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=chris@chrisdown.name \
--cc=corbet@lwn.net \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@meta.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan.x@bytedance.com \
--cc=lnyng@meta.com \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=nphamcs@gmail.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox