Re: [PATCH v4 1/1] memcg/hugetlb: Add hugeTLB counters to memcg

[Nhat Pham <nphamcs@gmail.com>]

On Wed, Nov 13, 2024 at 2:42 PM David Rientjes <rientjes@google.com> wrote:
>
> On Mon, 11 Nov 2024, David Rientjes wrote:
>
> >
> > If broken down into hugetlb_2048kB and hugetlb_1048576kB on x86, for
> > example, users could still do sum of memory.stat, no?>
> >
>
> Friendly ping on this, would there be any objections to splitting the
> memory.stat metrics out to be per hugepage size?

My 2c is that it's extra complexity + overhead (IIUC these stats are
hierarchical and hence would contribute to flushing overhead). So we
should justify them with some concrete use cases if we are to add
them.

From my end, I need hugetlb usage when I want to reason about memory
dynamics. This is because hugetlb is a bit special/weird - it cannot
be swapped out for e.g. So I have subtract hugetlb usage from overall
cgroup's memory usage before making any analysis that involves
swapping. For this use case, I just need to know how much memory is
consumed by hugetlb, regardless of the type (2M or 1G). I assume many
use cases are similar in that sense.

Do you or Google have a concrete use case in mind that requires
hugetlb categorization? :)