Re: [PATCH v2 10/10] riscv: Add qspinlock support based on Zabha extension

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/15/24 03:27, Alexandre Ghiti wrote:
Hi Guo,

On Sun, Jul 7, 2024 at 4:20 AM Guo Ren <guoren@xxxxxxxxxx> wrote:
On Wed, Jun 26, 2024 at 9:14 PM Alexandre Ghiti <alexghiti@xxxxxxxxxxxx> wrote:
In order to produce a generic kernel, a user can select
CONFIG_COMBO_SPINLOCKS which will fallback at runtime to the ticket
spinlock implementation if Zabha is not present.

Note that we can't use alternatives here because the discovery of
extensions is done too late and we need to start with the qspinlock
That's not true; we treat spinlock as qspinlock at first.
That's what I said: we have to use the qspinlock implementation at
first *because* we can't discover the extensions soon enough to use
the right spinlock implementation before the kernel uses a spinlock.
And since the spinlocks are used *before* the discovery of the
extensions, we cannot use the current alternative mechanism or we'd
need to extend it to add an "initial" value which does not depend on
the available extensions.

With qspinlock, the lock remains zero after a lock/unlock sequence. That is not the case with ticket lock. Assuming that all the discovery will be done before SMP boot, the qspinlock slowpath won't be activated and so we don't need the presence of any extension. I believe that is the main reason why qspinlock is used as the initial default and not ticket lock.

Cheers,
Longman





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux