linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: Wei Xu <weixugc@google.com>
Cc: David Hildenbrand <david@redhat.com>,
	Sourav Panda <souravpanda@google.com>,
	corbet@lwn.net,  gregkh@linuxfoundation.org, rafael@kernel.org,
	akpm@linux-foundation.org,  mike.kravetz@oracle.com,
	muchun.song@linux.dev, rppt@kernel.org,  rdunlap@infradead.org,
	chenlinxuan@uniontech.com, yang.yang29@zte.com.cn,
	 tomas.mudrunka@gmail.com, bhelgaas@google.com,
	ivan@cloudflare.com,  yosryahmed@google.com, hannes@cmpxchg.org,
	shakeelb@google.com,  kirill.shutemov@linux.intel.com,
	wangkefeng.wang@huawei.com,  adobriyan@gmail.com, vbabka@suse.cz,
	Liam.Howlett@oracle.com,  surenb@google.com,
	linux-kernel@vger.kernel.org,  linux-fsdevel@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-mm@kvack.org,
	 willy@infradead.org, Greg Thelen <gthelen@google.com>
Subject: Re: [PATCH v5 1/1] mm: report per-page metadata information
Date: Fri, 3 Nov 2023 11:18:53 -0400	[thread overview]
Message-ID: <CA+CK2bAWbnapxXvOwHFXFJNqzKP-_=vroyLaeWBQ=d-ZJ4_R3w@mail.gmail.com> (raw)
In-Reply-To: <CAAPL-u-nSLiObCC9Vbtdv1m8-87K-M6FcVcgnruGzRkAAucRTA@mail.gmail.com>

> > Since we are going to use two independent interfaces
> > /proc/meminfo/PageMetadata and nodeN/page_metadata (in a separate file
> > as requested by Greg) How about if in /proc/meminfo we provide only
> > the buddy allocator part, and in nodeN/page_metadata we provide the
> > total per-page overhead in the given node that include memblock
> > reserves, and buddy allocator memory?
>
> What we want is the system-wide breakdown of kernel memory usage. It
> works for this use case with the new PageMetadata counter in
> /proc/meminfo to report only buddy-allocated per-page metadata.

We want to report all PageMetadata, otherwise this effort is going to
be useless for the majority of users.

As you noted, /proc/meminfo allows us to report only the part of
per-page metadata that was allocated by the buddy allocator because of
an existing MemTotal bug that does not include memblock reserves.
However, we do not have this limitation when we create a new
nodeN/page_metadata interface, and we can document that in the sysfs
ABI documentation: sum(nodeN/page_metadata)  contains all per-page
metadata and is superset of /proc/meminfo.

The only question is how to name PageMetadata in the /proc/meminfo
appropriately, so users can understand that not all page metadata is
included? (of course we will also document that only the MemTotal part
of page metadata is reported in /proc/meminfo)

Pasha


  reply	other threads:[~2023-11-03 15:19 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-01 23:08 [PATCH v5 0/1] " Sourav Panda
2023-11-01 23:08 ` [PATCH v5 1/1] " Sourav Panda
2023-11-01 23:40   ` Wei Xu
2023-11-02  2:57     ` Pasha Tatashin
2023-11-02 15:43       ` Wei Xu
2023-11-02 15:47         ` David Hildenbrand
2023-11-02 15:50           ` Pasha Tatashin
2023-11-02 15:53             ` David Hildenbrand
2023-11-02 16:02               ` Pasha Tatashin
2023-11-02 16:09                 ` David Hildenbrand
2023-11-02 16:43                   ` Pasha Tatashin
2023-11-02 16:58                     ` David Hildenbrand
2023-11-02 17:11                       ` Pasha Tatashin
2023-11-02 18:06                         ` Wei Xu
2023-11-02 18:33                           ` Pasha Tatashin
2023-11-02 20:22                             ` Wei Xu
2023-11-03  1:06                               ` Pasha Tatashin
2023-11-03  4:27                                 ` Wei Xu
2023-11-03 15:18                                   ` Pasha Tatashin [this message]
2023-11-02 20:28                         ` David Hildenbrand
2023-11-02  5:42   ` Greg KH
2023-11-02 14:24     ` Pasha Tatashin
2023-11-02 14:28       ` Greg KH
2023-11-02 15:11         ` Pasha Tatashin
2023-11-02 10:19   ` Alexey Dobriyan
2023-11-17  2:42   ` kernel test robot
2023-11-20 21:47     ` Sourav Panda
2023-11-02 18:13 ` [PATCH v5 0/1] " Matthew Wilcox
2023-11-03  4:53   ` Sourav Panda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+CK2bAWbnapxXvOwHFXFJNqzKP-_=vroyLaeWBQ=d-ZJ4_R3w@mail.gmail.com' \
    --to=pasha.tatashin@soleen.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhelgaas@google.com \
    --cc=chenlinxuan@uniontech.com \
    --cc=corbet@lwn.net \
    --cc=david@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gthelen@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=ivan@cloudflare.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=muchun.song@linux.dev \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=rppt@kernel.org \
    --cc=shakeelb@google.com \
    --cc=souravpanda@google.com \
    --cc=surenb@google.com \
    --cc=tomas.mudrunka@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=wangkefeng.wang@huawei.com \
    --cc=weixugc@google.com \
    --cc=willy@infradead.org \
    --cc=yang.yang29@zte.com.cn \
    --cc=yosryahmed@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox