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

[John Hubbard <jhubbard@nvidia.com>]

On 11/27/23 02:31, Ryan Roberts wrote:
> On 27/11/2023 08:20, Alistair Popple wrote:
>> David Hildenbrand <david@redhat.com> writes:
>>> On 24.11.23 16:53, Matthew Wilcox wrote:
>>>> On Fri, Nov 24, 2023 at 04:25:38PM +0100, David Hildenbrand wrote:
>>>>> On 24.11.23 16:13, Matthew Wilcox wrote:
>>>>>> On Fri, Nov 24, 2023 at 09:56:37AM +0000, Ryan Roberts wrote:
>>>>>>> On 23/11/2023 15:59, Matthew Wilcox wrote:
>>>>>>>> On Wed, Nov 22, 2023 at 04:29:40PM +0000, Ryan Roberts wrote:
...
>>> Maybe that's the reason why FreeBSD calls them "medium-sized
>>> superpages", because "Medium-sized" seems to be more appropriate to
>>> express something "in between".
>>
>> Transparent Medium Pages?

I enjoyed this suggestion, because the resulting acronym is TMP. Which
*might* occasionally lead to confusion. haha :)

> 
> I don't think this is future proof; If we are going to invent a new term, it
> needs to be indpendent of size to include all sizes including PMD-size and
> perhaps in future, bigger-than-PMD-size. I think generalizing the meaning of
> "huge" in THP to mean "bigger than the base page" is the best way to do this.
> Then as David says, over time people will qualify it with a specific size when
> appropriate.
> 
>>
>>> So far I thought the reason was because they focused on 64k only.
>>>
>>> Never trust a German guy on naming suggestions. John has so far been
>>> my naming expert, so I'm hoping he can help.
>>
>> Likewise :-)
>>

I appreciate the call-out, although my latest suggestion seems to have
gotten buried in the avalanche of discussions. I'm going to revive it and
try again, though.

>>> "Sub-pmd-sized THP" is just mouthful. But then, again, this is would
>>> just be a temporary name, and in the future THP will just naturally
>>> come in multiple sizes (and others here seem to agree on that).
> 
> I actually don't mind "sub-pmd-sized THP" given the few locations its actually
> going to live.
> 
>>>
>>>
>>> But just to repeat: I don't think there is need to come up with new
>>> terminology and that there will be mass-confusion. So far I've not
>>> heard a compelling argument besides "one memory counter could confuse
>>> an admin that explicitly enables that new behavior.".
>>>
>>> Side note: I'm, happy that we've reached a stage where we're
>>> nitpicking on names :)
>>
> 
> 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


thanks,
-- 
John Hubbard
NVIDIA