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.
