linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Ye Liu <ye.liu@linux.dev>
Cc: David Hildenbrand <david@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ye Liu <liuye@kylinos.cn>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/vmstat: add header line to /proc/buddyinfo output
Date: Thu, 18 Sep 2025 10:49:59 +0200	[thread overview]
Message-ID: <aMvHt7Z2PMuZaned@tiehlicka> (raw)
In-Reply-To: <6d6e2e33-c221-4ab8-a29b-3d14fb1a592c@linux.dev>

On Thu 18-09-25 16:31:22, Ye Liu wrote:
> 
> 
> 在 2025/9/18 16:16, David Hildenbrand 写道:
> > On 18.09.25 10:11, Ye Liu wrote:
> >>
> >>
> >> 在 2025/9/18 15:29, Michal Hocko 写道:
> >>> On Thu 18-09-25 15:17:40, Ye Liu wrote:
> >>>> From: Ye Liu <liuye@kylinos.cn>
> >>>>
> >>>> Add a header line to /proc/buddyinfo that shows the order numbers
> >>>> for better readability and clarity.
> >>>>
> >>>> Before:
> >>>> Node 0, zone      DMA      0      0      0      0      0      0      0 ...
> >>>> Node 0, zone    DMA32      5      8      6      6      7      5      8 ...
> >>>> Node 0, zone   Normal   1113    351    138     65     38     31     25 ...
> >>>>
> >>>> After:
> >>>> Free pages per order       0      1      2      3      4      5      6 ...
> >>>> Node 0, zone      DMA      0      0      0      0      0      0      0 ...
> >>>> Node 0, zone    DMA32      5      8      6      6      7      5      8 ...
> >>>> Node 0, zone   Normal   1113    351    138     65     38     31     25 ...
> >>>
> >>> Why is this needed? And have you considered tha this might break
> >>> existing parsers of the file?
> >>>
> >>
> >> Thanks for the review.
> >>
> >> The reason for this change is simply to make /proc/buddyinfo self-describing.
> >> Right now you have to know which column is which order; with a header it’s
> >> obvious. This is similar to what /proc/pagetypeinfo already does, e.g.:
> >>
> >>    Page block order: 9
> >>    Pages per block: 512
> >>
> >>    Free pages count per migrate type at order   0 1 2 3 ...
> >>    Node 0, zone DMA, type Unmovable             0 0 0 ...
> >>
> >> Regarding existing parsers: the patch does not change any of the existing
> >> “Node … zone …” lines, it only adds a single header line before them. Most
> >> parsers match “Node” lines and ignore everything else, so the risk should be
> >> low. If you know of any existing parser that this would break, please let
> >> me know so I can address it.
> > 
> > What if there is a single one out there that has hardcoded to skip the first line only?
> 
> I understand there may be no way to be fully compatible with all existing
> parsers. However, /proc/buddyinfo is essentially raw data intended for
> human and tool consumption, and parsers are expected to be robust against
> format changes.

I am pretty sure you can create a trivial wrapper to print that header,
right?

> Adding a '#' prefix to the header would allow most parsers to skip it,
> but it still changes the file output and cannot fully guarantee that no
> external tool will be affected.                                          

That still assumes that they expect something like that.
We are trying really hard to not break existing userspace even if it is
not written in a robust way. That is simply how Linux kernel handles all
the existing interfaces. There must be a very serious reason to add a
change that might _theoretically_ breaker existing userspace. What you
are proposing here is not such a reason as it is trivial to achieve what
you want from the userspace.

NAK to the change.
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2025-09-18  8:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-18  7:17 Ye Liu
2025-09-18  7:29 ` Michal Hocko
2025-09-18  8:11   ` Ye Liu
2025-09-18  8:16     ` David Hildenbrand
2025-09-18  8:31       ` Ye Liu
2025-09-18  8:49         ` Michal Hocko [this message]
2025-09-18  9:00           ` Ye Liu
2025-09-18  8:50         ` David Hildenbrand

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=aMvHt7Z2PMuZaned@tiehlicka \
    --to=mhocko@suse.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liuye@kylinos.cn \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=ye.liu@linux.dev \
    /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