Re: [PATCH v4 12/12] xen/spinlock: support higher number of cpus

From: Julien Grall <julien@xen.org>
To: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
	javi.merino@cloud.com
Subject: Re: [PATCH v4 12/12] xen/spinlock: support higher number of cpus
Date: Tue, 12 Dec 2023 11:40:44 +0000	[thread overview]
Message-ID: <e5d991d7-cfdb-4970-90e9-c43fc16cdba0@xen.org> (raw)
In-Reply-To: <29a4894c-6a08-49cb-9567-c952eaaffa0f@suse.com>

Hi Juergen,

On 12/12/2023 11:09, Juergen Gross wrote:
> On 12.12.23 11:10, Julien Grall wrote:
>> Hi Juergen,
>>
>> On 12/12/2023 09:47, Juergen Gross wrote:
>>> Allow 16 bits per cpu number, which is the limit imposed by
>>> spinlock_tickets_t.
>>>
>>> This will allow up to 65535 cpus, while increasing only the size of
>>> recursive spinlocks in debug builds from 8 to 12 bytes.
>> Looking at arch/Kconfig, it looks like we are limiting NR_CPUS to 
>> maximum 4096. So can you outline why we need this?
> 
> The limit of 4096 cpus is dictated by the current limit of the spinlock
> implementation. So asking "why do we need to support more than 4096 cpus
> in spinlock_t when the current Xen limit is 4096" is kind of the wrong
> question. >
> The correct question would be: why is Xen limited to 4096 cpus? Answer:
> because of the limit in spinlock_t.

I thought there was also some lock contention issue in Xen. Hence why I 
asked the question because the commit message doesn't really give any 
clue why we are raising the limit... (This is a hint that it probably 
needs to be expanded a bit).

Cheers,

-- 
Julien Grall