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

[John Hubbard <jhubbard@nvidia.com>]

On 1/5/24 00:35, Ryan Roberts wrote:
> right aligned with 0 or ' ' as the pad? I guess ' ' if you want it to look like
> ps? But given pid is the first column, I think it will look weird right aligned.
> Perhaps left aligned, followed by colon, followed by pad? Here are the 3 options:

I will leave all of the alignment to your judgment and good taste. I'm sure
it will be fine.

(I'm not trying to make the output look like ps(1). I'm trying to make the pid
look like it "often" looks, and I used ps(1) as an example.)

> 
> 00000206: 0000aaaadbb20000-0000aaaadbb21000 r-xp 00000000 fe:00 00426969
>       206: 0000aaaadbb20000-0000aaaadbb21000 r-xp 00000000 fe:00 00426969

Sure.

> 206:      0000aaaadbb20000-0000aaaadbb21000 r-xp 00000000 fe:00 00426969
> 
> My personal preference is the first option; right aligned with 0 pad.
> 
>>
>> b) In fact, perhaps a header row would help. There could be a --no-header-row
>>     option for cases that want to feed this to other scripts, but the default
>>     would be to include a human-friendly header.
> 
> How about this for a header (with example first data row):
> 
>       PID             START              END PROT      OFF MJ:MN    INODE FILE

I need to go look up with the MJ:MN means, and then see if there is a
less mysterious column name.

> 00000206: 0000aaaadbb20000-0000aaaadbb21000 r-xp 00000000 fe:00 00426969
> 
> Personally I wouldn't bother with a --no-header option; just keep it always on.
> 
>>
>> c) pid should probably be suppressed if --pid is specified, but that's
>>     less important than the other points.
> 
> If we have the header then I think its clear what it is and I'd prefer to keep
> the data format consistent between --pid and --cgroup. So prefer to leave pid in
> always.
>

That sounds reasonable to me.
  
>>
>> In a day or two I'll get a chance to run this on something that allocates
>> lots of mTHPs, and give a closer look.
> 
> Thanks - it would be great to get some feedback on the usefulness of the actual
> counters! :)

Working on it!

> 
> I'm considering adding an --ignore-folio-boundaries option, which would modify
> the way the cont counters work, to only look for contiguity and alignment and
> ignore any folio boundaries. At the moment, if you have multiple contiguous
> folios, they don't count, because the memory doesn't all belong to the same
> folio. I think this could be useful in some (limited) circumstances.
> 

This sounds both potentially useful, and yet obscure, so I'd suggest waiting
until you see a usecase. And then include the usecase (even if just a comment),
so that it explains both how to use it, and why it's useful.

thanks,
-- 
John Hubbard
NVIDIA