On 28/11/2023 18:39, John Hubbard wrote: > On 11/28/23 07:34, Ryan Roberts wrote: >> 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: >>>> 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. > > Sounds workable to me, too. > >> >>> >>> 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. > > OK. > >> >>> >>> 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. >> > > We do want to have at least some way to verify that mTHP is active from > day 0, though. Could you clarify what you mean by "active"? Current plan is that there will be a per-size transparent_hugepage/hugepages-<size>kB/enabled sysfs file that can be querried to see if the size is enabled (available for the kernel to use). But for this initial submission, we previously agreed (well, at least David and I) that not having a full set of stats is not a problem - they can come later. So the only way to verify that the kernel is allocating and mapping a particular THP size is to parse /proc/<pid>pagemap and look at the PFNs for now. Is that sufficient? > > > thanks,
