Message-ID: <20241114164236.1790279-1-joshua.hahnjy@gmail.com>
Date: Thu, 14 Nov 2024 08:42:15 -0800
From: Joshua Hahn <joshua.hahnjy@...il.com>
To: David Rientjes <rientjes@...gle.com>
Cc: akpm@...ux-foundation.org,
	hannes@...xchg.org,
	nphamcs@...il.com,
	shakeel.butt@...ux.dev,
	roman.gushchin@...ux.dev,
	muchun.song@...ux.dev,
	chris@...isdown.name,
	tj@...nel.org,
	lizefan.x@...edance.com,
	mkoutny@...e.com,
	corbet@....net,
	lnyng@...a.com,
	cgroups@...r.kernel.org,
	linux-mm@...ck.org,
	linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	kernel-team@...a.com
Subject: Re: [PATCH v4 1/1] memcg/hugetlb: Add hugeTLB counters to memcg

On Wed, 13 Nov 2024 14:42:29 -0800 (PST) David Rientjes <rientjes@...gle.com> wrote:

Hi David,

Sorry for the late response on this thread. To be completely transparent
with you, I am not someone who inspects hugetlb usage on a regular
basis, so I may not have the most relevant insights when it comes to
how much utility there would be from breaking down the usage by size.

With that said, I believe that over the past couple of days, there have
been some responses on this thread regarding how others use hugetlb. As you
know, I share Johannes's opinion that if there are people who would benefit
from splitting up the hugetlb usage across different page sizes, it should
happen in the hugetlb controller. 

> On Mon, 11 Nov 2024, David Rientjes wrote:
> > While the patch may be minimal, this is solidifying a kernel API that 
> > users will start to count on.  Users who may be interested in their 
> > hugetlb usage may not have control over the configuration of their kernel?

This is a good point. With that said, I believe that this is an instance
of a feature where both of our proposed ideas can co-exist; we can have the
total hugetlb usage reported in memcg for now, and if there is a consensus 
/ majority that would like to see the breakdown as well, we can introduce
it in a future patch without breaking the utility of this patch.

To quickly address a potential concern of bloating the already large memcg
stat: including both the total and breakdown wouldn't be the first time
a stat and its breakdown are both included: there is a precedent with this
in slab_(un)reclaimable and slab. 

> > Does it make sense to provide a breakdown in memory.stat so that users can 
> > differentiate between mapping one 1GB hugetlb page and 512 2MB hugetlb 
> > pages, which are different global resources?
> > 
> > > 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.
> > > 
> > 
> > If broken down into hugetlb_2048kB and hugetlb_1048576kB on x86, for 
> > example, users could still do sum of memory.stat, no?>

This is true! I still think it would be nice to include the total anyways,
since for a lot of people who use this statistic (Nhat's response in this
thread and Shakeel's response in the v3 of this patch), all they want is
a quick check to see how much memory is being used by hugetlb so they can
reason about memory dynamics. Again, I think that if we are to include
a breakdown in a future patch, it can coexist with this one.

> Friendly ping on this, would there be any objections to splitting the 
> memory.stat metrics out to be per hugepage size?

Sorry for the late reponse again. I think that if you had examples of use
cases where having the differnt page sizes, it would help me better
understand a motivation for including the breakdown (I would be happy
to write the patch for the breakdown as well if there is a consensus!)

Thank you for your thoughts, have a great day!
Joshua

Powered by blists - more mailing lists