[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJF2gTS40Em7Yi=fiQ=cMeRNNT+MRZ7tfGqRh=OjTiXMmpBX1w@mail.gmail.com>
Date: Sun, 22 Dec 2024 11:57:10 +0800
From: Guo Ren <guoren@...nel.org>
To: Radim Krčmář <rkrcmar@...tanamicro.com>
Cc: paul.walmsley@...ive.com, palmer@...belt.com, bjorn@...osinc.com,
conor@...nel.org, leobras@...hat.com, alexghiti@...osinc.com,
atishp@...osinc.com, apatel@...tanamicro.com, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org, parri.andrea@...il.com,
Guo Ren <guoren@...ux.alibaba.com>
Subject: Re: [PATCH] riscv: qspinlock: Add virt_spin_lock() support for KVM guests
On Mon, Dec 16, 2024 at 5:47 PM Radim Krčmář <rkrcmar@...tanamicro.com> wrote:
>
> 2024-12-15T11:13:22-0500, guoren@...nel.org:
> > Add a static key controlling whether virt_spin_lock() should be
> > called or not. When running on bare metal set the new key to
> > false.
>
> Wouldn't re-using the combo spinlock qspinlock_key be better?
>
> > The VM guests should fall back to a Test-and-Set spinlock,
> > because fair locks have horrible lock 'holder' preemption issues.
> > The virt_spin_lock_key would shortcut for the queued_spin_lock_-
> > slowpath() function that allow virt_spin_lock to hijack it.
>
> I think we want the proper paravirtualized slowpath, have the
> discussions stalled on the SBI side?
Here is the up-to-date paravirtualized slowpath version:
https://lore.kernel.org/linux-riscv/20241222033917.1754495-1-guoren@kernel.org/
We could continue the discussion on the SBI spec side.
>
> Btw. how bad are the performance numbers without this patch?
>
> Thanks.
--
Best Regards
Guo Ren
Powered by blists - more mailing lists