On Thu, Feb 8, 2024 at 4:25 PM Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > > On Thu, Feb 08, 2024 at 03:50:12PM -0800, Wei Xu wrote: > > On Thu, Feb 8, 2024 at 10:08 AM Pasha Tatashin > > <pasha.tatashin@xxxxxxxxxx> wrote: > > > > > > > > I am not closely following this series, but I just wanted to point out > > > > > that this is not always true. We are actively extending > > > > > NR_SECONDARY_PAGETABLE to add IOMMU page tables in addition to KVM > > > > > page tables [1]. In that case as well, the name was left open-ended > > > > > exactly for this purpose [2]. > > > > > > > > I think you're glossing over quite some nuance here. > > > > > > > > Sure there might be highly specific scenarios where you can get away > > > > with it. Like with a very recently introduced counter for somewhat > > > > niche audiences, and bucketing/grouping that was IIRC planned from the > > > > start. It's probably not reasonable to advocate nondescript interface > > > > names as a strategy for getting out of ABI commitments. > > > > > > > > My point was that "memmap" is the established term for what the author > > > > describes. And that this concept is sufficiently first-class that > > > > mixing it with other things later is unlikely to be acceptable. I > > > > didn't know WHY a new name for this was chosen, so I provided > > > > arguments for two motivations that I could think of, that's all. > > > > > > Sure, we can rename it to NR_MEMMAP_BOOT / NR_MEMMAP. We picked > > > NR_PAGE_METADATA_BOOT/NR_PAGE_METADATA as we thought it was a clearer > > > choice. It directly conveys the concept of page metadata overhead, > > > eliminating ambiguity about future potential structures. Today, it is > > > "struct page", and "pag_ext", tomorrow memdesc and more. > > > > Technically, page_ext is not part of memmap if we go by the kernel code, right? > > From a user POV it's the same: the fixed linear overhead of mapping > out physical memory for kernel use. struct page is the build-time > component, struct page_ext is the boot-time component, but I'd say > that distinction is mostly just an implementation detail. > > If between memdesc, folio, slab etc. struct page disappears entirely > some day, "memmap" remains a valid concept and a cost of interest. "memmap" is not a meaningful concept to the userspace. If we choose it because it is well-known within the kernel code, someday some kernel engineers may be surprised to see non-memmap overheads get reported as "memmap". Anyway, I don't have a strong opinion on this field name. Just want to point out this potential issue.
