Re: [PATCH V2 2/2] LoongArch: Add qspinlock support

[Huacai Chen <chenhuacai@kernel.org>]

Hi, Arnd,

On Sat, Jun 25, 2022 at 7:49 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Sat, Jun 25, 2022 at 8:54 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > On Thu, Jun 23, 2022 at 10:04 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Thu, Jun 23, 2022 at 3:05 PM Huacai Chen <chenhuacai@kernel.org> 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?
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.
OK, this will be added to the commit message.

>
> 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.
OK, the dependency seems to make sense.

Huacai
>
>            Arnd
>