> > > I could have sworn that I pointed that out in a previous version and > > > requested to document that special case in the patch description. :) > > > > Sounds, good we will document that parts of per-page may not be part > > of MemTotal. > > But this still doesn't answer how we can use the new PageMetadata > field to help break down the runtime kernel overhead within MemUsed > (MemTotal - MemFree). I am not sure it matters to the end users: they look at PageMetadata with or without Page Owner, page_table_check, HugeTLB and it shows exactly how much per-page overhead changed. Where the kernel allocated that memory is not that important to the end user as long as that memory became available to them. In addition, it is still possible to estimate the actual memblock part of Per-page metadata by looking at /proc/zoneinfo: Memblock reserved per-page metadata: "present_pages - managed_pages" If there is something big that we will allocate in that range, we should probably also export it in some form. If this field does not fit in /proc/meminfo due to not fully being part of MemTotal, we could just keep it under nodeN/, as a separate file, as suggested by Greg. However, I think it is useful enough to have an easy system wide view for Per-page metadata. > > > > are allocated), so what would be the best way to export page metadata > > > > without redefining MemTotal? Keep the new field in /proc/meminfo but > > > > be ok that it is not part of MemTotal or do two counters? If we do two > > > > counters, we will still need to keep one that is a buddy allocator in > > > > /proc/meminfo and the other one somewhere outside? > > > > > I think the simplest thing to do now is to only report the buddy > allocations of per-page metadata in meminfo. The meaning of the new This will cause PageMetadata to be 0 on 99% of the systems, and essentially become useless to the vast majority of users.
