Re: [PATCH v2 9/9] xen: introduce a Kconfig option to configure NUMA nodes number

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.07.2022 09:51, Wei Chen wrote:
>> From: Julien Grall <julien@xxxxxxx>
>> Sent: 2022年7月14日 19:27
>>
>> On 14/07/2022 12:10, Jan Beulich wrote:
>>> On 14.07.2022 12:14, Wei Chen wrote:
>>>>> From: Jan Beulich <jbeulich@xxxxxxxx>
>>>>> Sent: 2022年7月12日 22:34
>>>>>
>>>>> 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.
>>>
>>> The defaults are fine. But does it make sense to have 255 nodes when
>>> just 32 CPUs were selected? I'm afraid kconfig is going to get in the
>>> way, but I think I'd like the upper bound to be min(NR_CPUS, 255).
>>
>> Looking around NUMA nodes with 0 CPUs exists. So I don't think we should
>> tie the two.
>>
> 
> Yes, some nodes can only have RAM and some nodes can only have CPUs.
> So is it ok to use 2-255 for node range?

Personally I think we shouldn't allow unreasonably high node counts,
unless proven by real hardware existing. Which goes hand in hand with
me wanting the upper bound to be a power of 2 value, if for nothing
else than a hint that using power-of-2 values here is preferable.
Hence I'd like to propose 64 or 128 as upper bound, in this order of
(my personal) preference.

Jan