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.

Therefore my suggestion would be to only (mention) go(ing) up to 32k.

Signed-off-by: Juergen Gross <jgr...@suse.com>
---
  xen/common/spinlock.c      |  1 +
  xen/include/xen/spinlock.h | 18 +++++++++---------
  2 files changed, 10 insertions(+), 9 deletions(-)

Shouldn't this also bump the upper bound of the NR_CPUS range then
in xen/arch/Kconfig?

Fine with me, I can add another patch to the series doing that.


Juergen

Reply via email to