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

[Johannes Weiner <hannes@cmpxchg.org>]

On Wed, Feb 07, 2024 at 07:27:34PM -0800, Yosry Ahmed wrote:
> > >
> > > Adds two new per-node fields, namely nr_page_metadata and
> > > nr_page_metadata_boot, to /sys/devices/system/node/nodeN/vmstat and a
> > > global PageMetadata field to /proc/meminfo.  This information can be used
> > > by users to see how much memory is being used by per-page metadata, which
> > > can vary depending on build configuration, machine architecture, and
> > > system use.
> >
> > /me wonders what page metadata is.
> >
> > > Per-page metadata is the amount of memory that Linux needs in order to
> > > manage memory at the page granularity.  The majority of such memory is
> > > used by "struct page" and "page_ext" data structures.
> >
> > The term for this in Linux MM is "memmap".
> >
> > That's what's used throughout the code, in Kconfig options, and it
> > shows up in the documentation as well. It's in the names of most files
> > and functions that adjust your new counters. The new name is
> > unnecessary, and frankly it's quite vague and nondescript.
> >
> > Also no reason to keep the stat name intentionally "open ended". As
> > became clear from the side discussions on MemTotal, all proposals to
> > change the semantics of counters later on will be nacked on the basis
> > of established user expectations. So just call it what it is now.
> 
> 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.