Re: [PATCH v9 1/1] mm: report per-page metadata information

[Sourav Panda <souravpanda@google.com>]

[-- Attachment #1: Type: text/plain, Size: 3443 bytes --]

On Wed, Apr 10, 2024 at 4:58 PM David Rientjes <rientjes@google.com> wrote:

> On Tue, 19 Mar 2024, Andrew Morton wrote:
>
> > On Tue, 20 Feb 2024 13:45:58 -0800 Sourav Panda <souravpanda@google.com>
> 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.
>

[-- Attachment #2: Type: text/html, Size: 4436 bytes --]