On Wed, Apr 10, 2024 at 4:58 PM David Rientjes <rientjes@xxxxxxxxxx> wrote:
On Tue, 19 Mar 2024, Andrew Morton wrote:
> On Tue, 20 Feb 2024 13:45:58 -0800 Sourav Panda <souravpanda@xxxxxxxxxx> wrote:
>
> > Adds two new per-node fields, namely nr_memmap and nr_memmap_boot,
> > to /sys/devices/system/node/nodeN/vmstat and a global Memmap 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.
>
> I yield to no man in my admiration of changelogging but boy, that's a
> lot of changelogging. Would it be possible to consolidate the [0/N]
> coverletter and the [1/N] changelog into a single thing please?
>
> > Documentation/filesystems/proc.rst | 3 +++
> > fs/proc/meminfo.c | 4 ++++
> > include/linux/mmzone.h | 4 ++++
> > include/linux/vmstat.h | 4 ++++
> > mm/hugetlb_vmemmap.c | 17 ++++++++++++----
> > mm/mm_init.c | 3 +++
> > mm/page_alloc.c | 1 +
> > mm/page_ext.c | 32 +++++++++++++++++++++---------
> > mm/sparse-vmemmap.c | 8 ++++++++
> > mm/sparse.c | 7 ++++++-
> > mm/vmstat.c | 26 +++++++++++++++++++++++-
> > 11 files changed, 94 insertions(+), 15 deletions(-)
>
> And yet we offer the users basically no documentation. The new sysfs
> file should be documented under Documentation/ABI somewhere and
> perhaps we could prepare some more expansive user-facing documentation
> elsewhere?
>
Sourav, is it possible to refresh this series into a v10 on top of the
latest upstream kernel with a single condensed changelog that details the
current behavior, what extension this is adding, and how it is generally
useful?
As noted here, the cover letter has great material that discusses the
rationale for this change but would be lost if only this patch is merged.
So typically the cover letter material gets concatenated into the
changelog, but in this case there's a lot of overlap.
A single patch that includes a succinct changelog would be awesome.
And then the requested documentation in Documentation/ABI either included
in the same patch or as a second patch in the series?
I don't think the resulting patch series will actually need a cover letter
after that, it will be able to stand on its own.
Thanks David, I will send v10 soon.
> I'd like to hear others' views on the overall usefulness/utility of this
> change, please?
>
Likely true for all hyperscalers, the immediate use case that this could
be applied to is to track boot memory overhead and any regression over
time (across kernel upgrades, firmware upgrades, etc) that may change the
amount of total memory available. We'd want to subtract out the boot
overhead that we know about (like struct page here) and then alert on any
regression where we're losing memory from reboot to reboot for any reason.
This increased visibility into boot memory overhead allows us to create a
mechanism to track changes over time when otherwise that attribution of
that memory is not available.
