Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Li,Rongqing" <lirongqing@baidu.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Yury Norov <yury.norov@gmail.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: 答复: [????] Re: [PATCH] nodemask: use nr_node_ids instead of MAX_NUMNODES in __nodemask_pr_numnodes()
Date: Fri, 10 Jul 2026 00:44:29 +0000	[thread overview]
Message-ID: <e86f64e7da3849e8b1be762f1ea14f3f@baidu.com> (raw)
In-Reply-To: <20260709164952.6630ce13f63a3104c2c53572@linux-foundation.org>

> On Thu, 9 Jul 2026 15:17:39 +0800 lirongqing <lirongqing@baidu.com>
> wrote:
> 
> > From: Li RongQing <lirongqing@baidu.com>
> >
> > __nodemask_pr_numnodes() returns MAX_NUMNODES, a compile-time
> > constant, as the width for '%*pb[l]' nodemask printing. On systems
> > with few NUMA nodes this produces excessive zero-padding, e.g. with
> > MAX_NUMNODES=1024 but only 2 nodes:
> >
> >   Mems_allowed: 00000000,00000000,...,00000003  (32 groups)
> 
> Please let's completely describe the effects of this.
> nodemask_pr_args() is used in several places so I believe that a number of
> userspace-facing strings will now appear differently?  Let's spell out which
> userspace interfaces are affected, and how.
> 

This affects every nodemask_pr_args() user.  Userspace-visible output
includes node state sysfs files under /sys/devices/system/node/, NVMe
multipath numa_nodes, memory tier nodelist, cpuset mems/effective_mems
files, /proc/<pid>/status Mems_allowed*, mempolicy strings such as those
shown in /proc/<pid>/numa_maps, and slub debugfs "nodes=" output.  Kernel
log messages that print nodemasks, such as cpuset warnings, allocation
failure warnings and OOM diagnostics, are affected as well.

The semantic value is unchanged.  Only the printed width changes from
MAX_NUMNODES bits to nr_node_ids bits, removing trailing zero words on
systems built with a large MAX_NUMNODES but booted with a smaller
possible-node range.  List outputs (%*pbl) remain unchanged for common
contiguous node ranges such as "0-1"; bitmap outputs (%*pb), such as
/proc/<pid>/status Mems_allowed, become shorter.


> > Use nr_node_ids (the runtime highest-node-id + 1) instead, matching
> > the behavior of cpumask_pr_args() which uses nr_cpu_ids:
> >
> >   Mems_allowed: 00000003
> >
> > Move the nr_node_ids declaration earlier in the file (guarded by
> > __nodemask_pr_numnodes(), and remove the now-duplicate declarations.
> >
> > ...
> >
> > --- a/include/linux/nodemask.h
> > +++ b/include/linux/nodemask.h
> > @@ -95,6 +95,12 @@
> >
> >  extern nodemask_t _unused_nodemask_arg_;
> >
> > +#if MAX_NUMNODES > 1
> > +extern unsigned int nr_node_ids;
> > +#else
> > +#define nr_node_ids		1U
> > +#endif
> > +
> >  /**
> >   * nodemask_pr_args - printf args to output a nodemask
> >   * @maskp: nodemask to be printed
> > @@ -105,7 +111,7 @@ extern nodemask_t _unused_nodemask_arg_;
> >  				__nodemask_pr_bits(maskp)
> >  static __always_inline unsigned int __nodemask_pr_numnodes(const
> > nodemask_t *m)  {
> > -	return m ? MAX_NUMNODES : 0;
> > +	return m ? nr_node_ids : 0;
> >  }
> >  static __always_inline const unsigned long *__nodemask_pr_bits(const
> > nodemask_t *m)  { @@ -438,7 +444,6 @@ static __always_inline
> unsigned
> > int next_memory_node(int nid)
> >  	return next_node(nid, node_states[N_MEMORY]);  }
> >
> > -extern unsigned int nr_node_ids;
> >  extern unsigned int nr_online_nodes;
> 
> Let's relocate nr_online_nodes also?  To keep them together.


I will relocate it in V2

Thanks

[Li,Rongqing] 



> 
> >  static __always_inline void node_set_online(int nid) @@ -480,7 +485,6
> > @@ static __always_inline int num_node_state(enum node_states state)
> >  #define first_memory_node	0
> >  #define next_online_node(nid)	(MAX_NUMNODES)
> >  #define next_memory_node(nid)	(MAX_NUMNODES)
> > -#define nr_node_ids		1U
> >  #define nr_online_nodes		1U
> >
> >  #define node_set_online(node)	   node_set_state((node), N_ONLINE)
> > --
> > 2.9.4


      reply	other threads:[~2026-07-10  0:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09  7:17 [PATCH] nodemask: use nr_node_ids instead of MAX_NUMNODES in __nodemask_pr_numnodes() lirongqing
2026-07-09 23:49 ` Andrew Morton
2026-07-10  0:44   ` Li,Rongqing [this message]

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=e86f64e7da3849e8b1be762f1ea14f3f@baidu.com \
    --to=lirongqing@baidu.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=yury.norov@gmail.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