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

[John Hubbard]

On 11/27/23 02:31, Ryan Roberts wrote:
> On 27/11/2023 08:20, Alistair Popple wrote:
> > David Hildenbrand <david@xxxxxxxxxx> 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