mm/vmstat.c | 7 +++++++ 1 file changed, 7 insertions(+)
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 ...
Signed-off-by: Ye Liu <liuye@kylinos.cn>
---
mm/vmstat.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/mm/vmstat.c b/mm/vmstat.c
index bb09c032eecf..e9606457ab91 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1574,7 +1574,14 @@ static void frag_show_print(struct seq_file *m, pg_data_t *pgdat,
*/
static int frag_show(struct seq_file *m, void *arg)
{
+ int order;
pg_data_t *pgdat = (pg_data_t *)arg;
+ /* Print header */
+ seq_printf(m, "%-21s ", "Free pages per order");
+ for (order = 0; order < NR_PAGE_ORDERS; ++order)
+ seq_printf(m, "%6d ", order);
+ seq_putc(m, '\n');
+
walk_zones_in_node(m, pgdat, true, false, frag_show_print);
return 0;
}
--
2.43.0On 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?
>
> Signed-off-by: Ye Liu <liuye@kylinos.cn>
> ---
> mm/vmstat.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index bb09c032eecf..e9606457ab91 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -1574,7 +1574,14 @@ static void frag_show_print(struct seq_file *m, pg_data_t *pgdat,
> */
> static int frag_show(struct seq_file *m, void *arg)
> {
> + int order;
> pg_data_t *pgdat = (pg_data_t *)arg;
> + /* Print header */
> + seq_printf(m, "%-21s ", "Free pages per order");
> + for (order = 0; order < NR_PAGE_ORDERS; ++order)
> + seq_printf(m, "%6d ", order);
> + seq_putc(m, '\n');
> +
> walk_zones_in_node(m, pgdat, true, false, frag_show_print);
> return 0;
> }
> --
> 2.43.0
>
--
Michal Hocko
SUSE Labs
在 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.
>>
>> Signed-off-by: Ye Liu <liuye@kylinos.cn>
>> ---
>> mm/vmstat.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/mm/vmstat.c b/mm/vmstat.c
>> index bb09c032eecf..e9606457ab91 100644
>> --- a/mm/vmstat.c
>> +++ b/mm/vmstat.c
>> @@ -1574,7 +1574,14 @@ static void frag_show_print(struct seq_file *m, pg_data_t *pgdat,
>> */
>> static int frag_show(struct seq_file *m, void *arg)
>> {
>> + int order;
>> pg_data_t *pgdat = (pg_data_t *)arg;
>> + /* Print header */
>> + seq_printf(m, "%-21s ", "Free pages per order");
>> + for (order = 0; order < NR_PAGE_ORDERS; ++order)
>> + seq_printf(m, "%6d ", order);
>> + seq_putc(m, '\n');
>> +
>> walk_zones_in_node(m, pgdat, true, false, frag_show_print);
>> return 0;
>> }
>> --
>> 2.43.0
>>
>
--
Thanks,
Ye Liu
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? -- Cheers David / dhildenb
在 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. 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. > -- Thanks, Ye Liu
On 18.09.25 10:31, 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.
Let's take a look at a random one: pcp-buddyinfo.
Reading the source code [1] of the /proc/buddyinfo parser in
refresh_proc_buddyinfo() I have my doubts:
if ((fp = linux_statsfile("/proc/buddyinfo", buf, sizeof(buf))) == NULL)
return -oserror();
while (fgets(buf,sizeof(buf),fp) != NULL) {
char node_name[128];
char *zone_name;
unsigned int values[SPLIT_MAX];
i = read_node_name(buf, node_name);
i+=6; /* erase ", zone" */
read_buddyinfo(buf+i, read_buf, MAX_ORDER+1); /* read zone name and page order */
zone_name=read_buf[0];
for (i=0; i < MAX_ORDER; i++)
values[i] = strtoul(read_buf[i+1], NULL, 10);
for (i=0; i < proc_buddyinfo->nbuddys; i++) {
if (strcmp(proc_buddyinfo->buddys[i].node_name, node_name)==0 &&
strcmp(proc_buddyinfo->buddys[i].zone_name, zone_name)==0)
break;
}
Do you think that one would survive your changes?
https://github.com/performancecopilot/pcp/blob/main/src/pmdas/linux/proc_buddyinfo.c
--
Cheers
David / dhildenb
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
在 2025/9/18 16:49, Michal Hocko 写道: > 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. I’ll drop this change. -- Thanks, Ye Liu
© 2016 - 2025 Red Hat, Inc.