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

[Ryan Roberts <ryan.roberts@arm.com>]

On 05/01/2024 23:18, John Hubbard wrote:
> 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

I'm going to go with this version ^

>>       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.

Its the device major/minor number. I could just call it DEV (DEVICE is too long)

> 
>> 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,