Re: [PATCH v2 10/10] riscv: Add qspinlock support based on Zabha extension
From: Waiman Long
Date: Mon Jul 15 2024 - 15:30:44 EST
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