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

[Jan Beulich <jbeulich@suse.com>]

On 29.02.2024 18:04, Jürgen Groß wrote:
> On 29.02.24 17:54, Jan Beulich wrote:
>> On 29.02.2024 17:45, Juergen Gross wrote:
>>> On 29.02.24 17:31, Jan Beulich wrote:
>>>> On 29.02.2024 17:29, Jürgen Groß wrote:
>>>>> On 29.02.24 16:46, Jan Beulich wrote:
>>>>>> On 12.12.2023 10: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.
>>>>>>
>>>>>> I think we want to be more conservative here, for the case of there
>>>>>> being bugs: The CPU holding a lock may wrongly try to acquire it a
>>>>>> 2nd time. That's the 65536th ticket then, wrapping the value.
>>>>>
>>>>> Is this really a problem? There will be no other cpu left seeing the lock
>>>>> as "free" in this case, as all others will be waiting for the head to reach
>>>>> their private tail value.
>>>>
>>>> But isn't said CPU then going to make progress, rather than indefinitely
>>>> spinning on the lock?
>>>
>>> No, I don't think so.
>>
>> Hmm. If CPU0 takes a pristine lock, it'll get ticket 0x0000. All other
>> CPUs will get tickets 0x0001 ... 0xffff. Then CPU0 trying to take the lock
> 
> No, they'll get 0x0001 ... 0xfffe (only 65535 cpus are supported).
> 
>> again will get ticket 0x0000 again, which equals what .head still has (no
> 
> And the first cpu will get 0xffff when trying to get the lock again.

Oh, right. Still a little too close to the boundary for my taste ...

Jan