On 28/11/2023 14:09, David Hildenbrand wrote: > 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? Sure. > > 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). Sounds good to me. > > 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. Yes, but I think we are agreed this is future work.
