linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Sourav Panda <souravpanda@google.com>,
	corbet@lwn.net, rafael@kernel.org,  akpm@linux-foundation.org,
	mike.kravetz@oracle.com, muchun.song@linux.dev,  rppt@kernel.org,
	david@redhat.com, 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, weixugc@google.com
Subject: Re: [PATCH v5 1/1] mm: report per-page metadata information
Date: Thu, 2 Nov 2023 10:24:04 -0400	[thread overview]
Message-ID: <CA+CK2bDUaQDwgF-Q0vfNzHfXmn-QhnHTSE32_RfttHSGB7O3DA@mail.gmail.com> (raw)
In-Reply-To: <2023110205-enquirer-sponge-4f35@gregkh>

On Thu, Nov 2, 2023 at 1:42 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Nov 01, 2023 at 04:08:16PM -0700, Sourav Panda wrote:
> > Adds a new per-node PageMetadata field to
> > /sys/devices/system/node/nodeN/meminfo
>
> No, this file is already an abuse of sysfs and we need to get rid of it
> (it has multiple values in one file.)  Please do not add to the
> nightmare by adding new values.

Hi Greg,

Today, nodeN/meminfo is a counterpart of /proc/meminfo, they contain
almost identical fields, but show node-wide and system-wide views.

Since per-page metadata is added into /proc/meminfo, it is logical to
add into nodeN/meminfo, some nodes can have more or less struct page
data based on size of the node, and also the way memory is configured,
such as use of vmemamp optimization etc, therefore this information is
useful to users.

I am not aware of any example of where a system-wide field from
/proc/meminfo is represented as a separate sysfs file under node0/. If
nodeN/meminfo is ever broken down into separate files it will affect
all the fields in it the same way with or without per-page metadata

> Also, even if you did want to do this, you didn't document it properly
> in Documentation/ABI/ :(

 The documentation for the fields in nodeN/meminfo is only specified
in  Documentation/filesystems/proc.rst, there is no separate sysfs
Documentation for the fields in this file, we could certainly add
that.

Thank you,
Pasha


  reply	other threads:[~2023-11-02 14:24 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
2023-11-02 20:28                         ` David Hildenbrand
2023-11-02  5:42   ` Greg KH
2023-11-02 14:24     ` Pasha Tatashin [this message]
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+CK2bDUaQDwgF-Q0vfNzHfXmn-QhnHTSE32_RfttHSGB7O3DA@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=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