Re: + mm-report-per-page-metadata-information.patch added to mm-unstable branch

[Johannes Weiner <hannes@cmpxchg.org>]

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@soleen.com> 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.