On 19/10/2023 10:39 am, Jan Beulich wrote:
> On 19.10.2023 11:35, Andrew Cooper wrote:
>> On 19/10/2023 8:48 am, Jan Beulich wrote:
>>> 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.
>> Actually, I consider this series an improvement. The CPU limit is the
>> most urgent problem to fix.
>>
>> XenServer has just jumped to NR_CPUS=2k in order to support 2024's range
>> of hardware, and it's only going to be a couple of years more before
>> we're stuck given the current spinlocks.
>>
>> I do genuinely think the code and logic would be better without
>> recursive locks, but making that happen is going to be very invasive and
>> complicated.
>>
>> But in the meantime with spinlocks properly separated from recursive
>> locks, it becomes easier IMO to dissuade the introduction of new cases
>> while we unpick the existing ones.
>>
>> And so what if we do end up deleting recursive locks in a few years
>> time? That's not an argument against doing this untangling now.
> Of course if that was happening only in a few years time, the series
> here is still worthwhile to have. My question was rather towards us
> possibly eliminating recursive locks in the next release cycle.
I find it unlikely that we'd manage to do it in the next release cycle,
even if we did dedicate a significant portion of effort to it. There
are more urgent things too.
But the same argument works with several years substituted for months.
~Andrew