Hi Jan, > -----Original Message----- > From: Jan Beulich <[email protected]> > Sent: 2022年7月12日 22:34 > To: Wei Chen <[email protected]> > Cc: nd <[email protected]>; Andrew Cooper <[email protected]>; George > Dunlap <[email protected]>; Julien Grall <[email protected]>; Stefano > Stabellini <[email protected]>; Wei Liu <[email protected]>; Roger Pau Monné > <[email protected]>; [email protected] > Subject: Re: [PATCH v2 9/9] xen: introduce a Kconfig option to configure > NUMA nodes number > > On 08.07.2022 16:54, Wei Chen wrote: > > --- a/xen/arch/Kconfig > > +++ b/xen/arch/Kconfig > > @@ -17,3 +17,14 @@ config NR_CPUS > > For CPU cores which support Simultaneous Multi-Threading or > similar > > technologies, this the number of logical threads which Xen will > > support. > > + > > +config NR_NUMA_NODES > > + int "Maximum number of NUMA nodes supported" > > + range 1 255 > > + default "64" > > + depends on NUMA > > Does 1 make sense? That's not going to be NUMA then, I would say. >
Ok, we need at least 2 nodes to be a real NUMA. > Does the value being (perhaps far) larger than NR_CPUS make sense? > Arm has 128 default NR_CPUS (except some platforms) and x86 has 256. So I am not very clear about your comments about far larger? As my Understanding, one node has 2 or 4 cores are very common in a NUMA System. > Why does the range end at a not-power-of-2 value? (I was actually > going to suggest to have a shift value specified here, until > spotting that NODES_SHIFT isn't used anywhere else, and hence > you're rightfully deleting it.) > I think we have discussed about the 255 in v1. Because Xen is using u8 as nodeid_t, so 255 may be a upper bound. And if use a shift value, from a user perspective, I don't like it. It needs to be converted, not intuitive enough. It also limits my input range, even though my numerical values are reasonable. Yes, if a machine has 15 node, we can ask them to input 16, but why not let the users decide? instead of being forced to enter 16 by the program? > > + help > > + Controls the build-time size of various arrays and bitmaps > > + associated with multiple-nodes management. It is the upper bound > of > > + the number of NUMA nodes that the scheduler, memory allocation and > > + other NUMA-aware components can handle. > > Nit: indentation. > Ok. Cheers, Wei Chen > Jan
