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

[Nhat Pham]

On Wed, Nov 13, 2024 at 2:42 PM David Rientjes <rientjes@xxxxxxxxxx> 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? :)