On Sat, Jun 25, 2022 at 8:54 AM Huacai Chen <chenhuacai@xxxxxxxxxx> wrote:
> On Thu, Jun 23, 2022 at 10:04 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > On Thu, Jun 23, 2022 at 3:05 PM Huacai Chen <chenhuacai@xxxxxxxxxx> wrote:
> >
> > If there is an architected feature bit for the delay, does that mean that there
> > is a chance of CPUs getting released that set this to zero?
> I had an offline discussion with hardware engineers, they told me that
> it is a mandatory requirement for LoongArch to implement "exclusive
> access of ll" and "random delay of sc" for multi-core chips. Only
> single-core and dual-core processors (and not support multi-chip
> interconnection) are allowed to have no such features.
Ok, I see. I suppose the reason is that the dual-core version is safe
without the random backoff because all uses cases for qspinlock only
involve one CPU waiting for a lock, right?
Please put the explanation into the changelog text for the next version. It
might be helpful to also document this in the source code itself, maybe
with a boot-time assertion that checks for this guarantee to be held up,
and an explanation that this is required for using qspinlock.
Regardless of this, I think it still makes sense to use the same compile-time
logic that Guo Ren suggested for the risc-v version, offering a choice between
ticket spinlock and qspinlock when both make sense, possibly depending
on CONFIG_NR_CPUS and CONFIG_NUMA.
Arnd
