Re: [PATCH v2 00/13] xen/spinlock: make recursive spinlocks a dedicated type

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.10.2023 11:42, Juergen Gross wrote:
> 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 8191
> 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).
> 
> Changes in V2:
> - addressed comments by Jan Beulich
> - lots of additional cleanups
> - reorganized complete series
> 
> Juergen Gross (13):
>   xen/spinlock: fix coding style issues
>   xen/spinlock: reduce lock profile ifdefs
>   xen/spinlock: make spinlock initializers more readable
>   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: remove indirection through macros for spin_*() functions
>   xen/spinlock: support higher number of cpus

Before looking at patches 4 and onwards, I'd like us to settle on the future
of recursive locking in Xen, considering in particular Andrew's objections
to their use in the code base. If the plan was to eliminate them, I'd see
little point in reworking the infrastructure. I'd like to suggest that one
of us tries to remember to put this up as an agenda item for the next
Community Call. But of course the discussion can also happen right here; I
merely expect there might not be much of a reaction.

Jan