Re: [RESEND PATCH v7 00/10] Small-sized THP for anonymous memory

[David Hildenbrand <david@redhat.com>]

On 28.11.23 13:15, Ryan Roberts wrote:
> On 28/11/2023 08:48, David Hildenbrand wrote:
>>
>>>>
>>>> Agreed. We are bikeshedding here. But if we really can't swallow "small-sized
>>>> THP" then perhaps the most efficient way to move this forwards is to review the
>>>> documentation (where "small-sized THP" appears twice in order to differentiate
>>>> from PMD-sized THP) - its in patch 3. Perhaps it will be easier to come up with
>>>> a good description in the context of those prose? Then once we have that,
>>>> hopefully a term will fall out that I'll update the commit logs with.
>>>>
>>>
>>> I will see you over in patch 3, then. I've already looked at it and am going
>>> to suggest a long and a short name. The long name is for use in comments and
>>> documentation, and the short name is for variable fragments:
>>>
>>>        Long name:  "pte-mapped THPs"
>>>        Short names: pte_thp, or pte-thp
>>
>> The issue is that any THP can be pte-mapped, even a PMD-sized THP. However, the
>> "natural" way to map a PMD-sized THP is using a PMD.
>>
> 
> How about we just stop trying to come up with a term for the "small-sized THP"
> vs "PMD-sized THP" and instead invent a name that covers ALL THP:
> 
> "multi-size THP" vs "PMD-sized THP".
> 
> Then in the docs we can talk about how multi-size THP introduces the ability to
> allocate memory in blocks that are bigger than a base page but smaller than
> traditional PMD-size, in increments of a power-of-2 number of pages.

So you're thinking of something like "multi-size THP" as a feature name, 
and stating that for now we limit it to <= PMD size. mTHP would be the 
short name?

For the stats, we'd document that "AnonHugePages" and friends only count 
traditional PMD-sized THP for historical reasons -- and that 
AnonHugePages should have been called AnonHugePmdMapped (which we could 
still add as an alias and document why AnonHugePages is weird).

Regarding new stats, maybe an interface that indicates the actual sizes 
would be best. As discussed, extending the existing single-large-file 
statistics might not be possible and we'd have to come up with a new 
interface, that maybe completely lacks "AnonHugePages" and directly goes 
for the individual sizes.

-- 
Cheers,

David / dhildenb