Re: [PATCH v2] tools/mm: Add thpmaps script to dump THP usage info

[John Hubbard <jhubbard@nvidia.com>]

On 1/11/24 03:54, Ryan Roberts wrote:
...
> I'm not sure exectly what you are asking. The "cont" counters are counting
> blocks of contiguous, naturally aligned physical memory, which are also mapped
> contiguously and aligned. So a smaller --cont would always include all the
> memory captured in a larger --cont. In this case, its all the *file-backed*
> memory (as highighted in the label name) so nothing to do with (m)THP. But where
> you have THP, --cont doesn't care what the underlying THP size is as long as its
> requirements are met, so PMD-sized THPs would be included in e.g.
> *anon*-cont-aligned-128kB.
> 
> Note the the "--cont" counters don't directly count memory that is PTE-mapped
> with the contiguous bit set in the page table; it just counts memory that meets
> the alignment, size and mapping requirements. On arm64 systems with the contpte
> series, the contiguous bit would be used here, but its not a part of what's
> getting measured.
> 

The "cont" and "naturally aligned" terms are difficult here, even though
I'm familiar with the implementation. But putting on my systems
monitoring hat, these terms are not helping people as much as I'd like,
because:

a) "Contiguous" is not really a unique situation, so measuring large pages
    that are "contiguous" is confusing. All folios are contiguous, and
    anything a pte points to is contiguous as well. So --cont really
    throws off the user/reader.

b) "Naturally aligned" is also tricky. Because "natural" is not explained.
Here it means NAPOT (naturally aligned power of two, I saw that in the
riscv docs).

After spending a day or two exploring running systems with this, I'd
like to suggest:

1) measure "native PMD THPs" vs. pte-mapped mTHPs. This provides a lot
of information: mTHP is configured as expected, and is helping or not,
etc.

2) Not having to list out all the mTHP sizes would be nice. Instead,
just use the possible sizes from /sys/kernel/mm/transparent_hugepage/* ,
unless the user specifies sizes.

...
                          (e.g. /sys/fs/cgroup for cgroup-v2 or
>>>                          /sys/fs/cgroup/pids for cgroup-v1). Exactly one
>>>                          of --pid and --cgroup must be provided.
>>
>> Maybe we could add "--global" to that list. That would look, in order,
>> inside cgroups2 and cgroups, for a list of pids, and then run as if
>> --cgroup /sys/fs/cgroup or --cgroup /sys/fs/cgroup/pids were specified.
> 
> I think actually it might be better just to make global the default when neither
> --pid nor --cgroup are provided? And in this case, I'll just grab all the pids
> from /proc rather than traverse the cgroup hierachy, that way it will work on
> systems without cgroups. Does that work for you?

Yes! That was my initial idea, in fact, and after over-thinking it for
a while, it turned into the above. haha :)


thanks,
-- 
John Hubbard
NVIDIA