Hi Jan, > -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: 2022年8月25日 21:06 > To: Wei Chen <wei.c...@arm.com> > Cc: nd <n...@arm.com>; Andrew Cooper <andrew.coop...@citrix.com>; George > Dunlap <george.dun...@citrix.com>; Julien Grall <jul...@xen.org>; Stefano > Stabellini <sstabell...@kernel.org>; Wei Liu <w...@xen.org>; Roger Pau Monné > <roger....@citrix.com>; xen-devel@lists.xenproject.org > Subject: Re: [PATCH v3 6/6] xen: introduce a Kconfig option to configure > NUMA nodes number > > On 22.08.2022 04:58, Wei Chen wrote: > > Current NUMA nodes number is a hardcode configuration. This > > configuration is difficult for an administrator to change > > unless changing the code. > > > > So in this patch, we introduce this new Kconfig option for > > administrators to change NUMA nodes number conveniently. > > Also considering that not all architectures support NUMA, > > this Kconfig option only can be visible on NUMA enabled > > architectures. Non-NUMA supported architectures can still > > use 1 as MAX_NUMNODES. > > Especially the uses of "NUMA nodes number" make this read somewhat > odd. If I was to re-write all of this, it would become something > like: > > Currently the maximum number of NUMA nodes is a hardcoded value. > This provides little flexibility unless changing the code. > > Introduce a new Kconfig option to change the maximum number of > NUMA nodes conveniently. Also considering that not all > architectures support NUMA, this Kconfig option is only visible > on NUMA enabled architectures. Architectures not supporting NUMA > still use 1 for MAX_NUMNODES. >
Thanks, I will update the commit log. > > As NODES_SHIFT is currently unused, we're taking this > > opportunity to remove it. > > > > Signed-off-by: Wei Chen <wei.c...@arm.com> > > Acked-by: Jan Beulich <jbeul...@suse.com> > Thanks! > Note that there's an alternative with less #ifdef-ary: > > config NR_NUMA_NODES > int "Maximum number of NUMA nodes supported" if NUMA > range 2 64 if NUMA > default "1" if !NUMA > default "64" > > But I can see reasons why one might deem it better for there to > not be any CONFIG_NR_NUMA_NODES in the resulting .config when > !NUMA. > Is it because there are many places where alternative patches need to be added for #ifndef CONFIG_NR_NUMA_NODES? Cheers, Wei Chen > Jan
