mbox series

[v5,00/13] xen/spinlock: make recursive spinlocks a dedicated type

Message ID 20240314072029.16937-1-jgross@suse.com (mailing list archive)
Headers show
Series xen/spinlock: make recursive spinlocks a dedicated type | expand

Message

Jürgen Groß March 14, 2024, 7:20 a.m. UTC 
Instead of being able to use normal spinlocks as recursive ones, too,
make recursive spinlocks a special lock type.

This will make the spinlock structure smaller in production builds and
add type-safety.

This allows to increase the maximum number of physical cpus from 4095
to 65535 without increasing the size of the lock structure in production
builds (the size of recursive spinlocks in debug builds will grow to
12 bytes due to that change).

Note that rwlock handling is still limiting the number of cpus to 4095,
this is being taken care off in patch 12, which raises the rwlock limit
to 16384 cpus.

Iommu code imposes a limit of 16383 cpus.

Changes in V2:
- addressed comments by Jan Beulich
- lots of additional cleanups
- reorganized complete series

Changes in V3:
- addressed comments by Jan Beulich

Changes in V4:
- former patch 1 has already been applied
- fixed a coding style issue in patch 1

Changes in V5:
- new patches 1 + 10 + 12 + 13
- due to the recent Ghost-race patches the macro layer for calling
  spinlock functions is kept
- addressed comments

Juergen Gross (13):
  xen/spinlock: remove misra rule 21.1 violations
  xen/spinlock: introduce new type for recursive spinlocks
  xen/spinlock: rename recursive lock functions
  xen/spinlock: add rspin_[un]lock_irq[save|restore]()
  xen/spinlock: make struct lock_profile rspinlock_t aware
  xen/spinlock: add explicit non-recursive locking functions
  xen/spinlock: add another function level
  xen/spinlock: add missing rspin_is_locked() and rspin_barrier()
  xen/spinlock: split recursive spinlocks from normal ones
  xen/spinlock: let all is_locked and trylock variants return bool
  xen/spinlock: support higher number of cpus
  xen/rwlock: raise the number of possible cpus
  xen: allow up to 16383 cpus

 xen/arch/Kconfig              |   2 +-
 xen/arch/arm/domain.c         |   4 +-
 xen/arch/arm/mm.c             |   4 +-
 xen/arch/x86/domain.c         |  20 +--
 xen/arch/x86/include/asm/mm.h |   2 +-
 xen/arch/x86/mm.c             |  12 +-
 xen/arch/x86/mm/mem_sharing.c |  16 +--
 xen/arch/x86/mm/mm-locks.h    |   6 +-
 xen/arch/x86/mm/p2m-pod.c     |   6 +-
 xen/arch/x86/mm/p2m.c         |   4 +-
 xen/arch/x86/tboot.c          |   4 +-
 xen/common/domain.c           |   6 +-
 xen/common/domctl.c           |   4 +-
 xen/common/grant_table.c      |  10 +-
 xen/common/ioreq.c            |  54 ++++----
 xen/common/memory.c           |   4 +-
 xen/common/numa.c             |   4 +-
 xen/common/page_alloc.c       |  30 ++---
 xen/common/spinlock.c         | 235 +++++++++++++++++++++++++---------
 xen/drivers/char/console.c    |  38 +++---
 xen/drivers/passthrough/pci.c |   8 +-
 xen/include/xen/rwlock.h      |  18 +--
 xen/include/xen/sched.h       |  10 +-
 xen/include/xen/spinlock.h    | 174 ++++++++++++++++++-------
 24 files changed, 440 insertions(+), 235 deletions(-)

Comments

Jan Beulich March 14, 2024, 7:26 a.m. UTC | #1 
On 14.03.2024 08:20, Juergen Gross wrote:
> With lock handling now allowing up to 16384 cpus (spinlocks can handle
> 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for
> the number of cpus to be configured to 16383.
> 
> The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and
> QINVAL_MAX_ENTRY_NR required to be larger than 2 * CONFIG_NR_CPUS.

That's quite sad - I was really hoping we'd finally end up with a
power-of-2 upper bound.

Jan
Jürgen Groß March 14, 2024, 10:14 a.m. UTC | #2 
On 14.03.24 08:26, Jan Beulich wrote:
> On 14.03.2024 08:20, Juergen Gross wrote:
>> With lock handling now allowing up to 16384 cpus (spinlocks can handle
>> 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for
>> the number of cpus to be configured to 16383.
>>
>> The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and
>> QINVAL_MAX_ENTRY_NR required to be larger than 2 * CONFIG_NR_CPUS.
> 
> That's quite sad - I was really hoping we'd finally end up with a
> power-of-2 upper bound.

Yes, me too.


Juergen