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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKEwX=NYPoEHKtXG_j_EL8XBkYJbYK_84XUi+JioGN5SnpLg0g@mail.gmail.com>
Date: Wed, 13 Nov 2024 17:08:25 -0800
From: Nhat Pham <nphamcs@...il.com>
To: David Rientjes <rientjes@...gle.com>
Cc: Joshua Hahn <joshua.hahnjy@...il.com>, akpm@...ux-foundation.org, hannes@...xchg.org, 
	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, Nov 13, 2024 at 2:42 PM David Rientjes <rientjes@...gle.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? :)