Hi, Arnd, On Sat, Jun 25, 2022 at 7:49 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > 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? 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 >
