On Tue, Jul 16, 2024 at 3:30 AM Waiman Long <longman@xxxxxxxxxx> wrote: > > 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. Thx Waiman, Yes, qspinlock is a clean guy, but ticket lock is a dirty one. Hi Alexandre, Therefore, the switch point(before reset_init()) is late enough to change the lock mechanism, and this satisfies the requirements of apply_boot_alternatives(), apply_early_boot_alternatives(), and apply_module_alternatives(). > > Cheers, > Longman > -- Best Regards Guo Ren
