From: Liangyan <liangyan.peng@bytedance.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Bibo Mao <maobibo@loongson.cn>,
pbonzini@redhat.com, vkuznets@redhat.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, wanpengli@tencent.com,
linux-kernel@vger.kernel.org, x86@kernel.org,
kvm@vger.kernel.org
Subject: Re: [External] Re: [PATCH RFC] x86/kvm: Use native qspinlock by default when realtime hinted
Date: Fri, 4 Jul 2025 14:12:04 +0800 [thread overview]
Message-ID: <dc4d14c5-1f04-47d7-b314-e4db62f57665@google.com> (raw)
In-Reply-To: <aGVdykqnaUnPBkW-@char.us.oracle.com>
Find one AMD guest(AMD EPYC 9Y24 128-vCPU) to test, it seems about 9%
improvement.
Command: ./Run -c 128 spawn
With virt spin lock:
System Benchmarks Partial Index BASELINE RESULT INDEX
Process Creation 126.0 120449.8 9559.5
========
System Benchmarks Index Score (Partial Only 9559.5
With qspinlock:
System Benchmarks Partial Index BASELINE RESULT INDEX
Process Creation 126.0 131566.8 10441.8
========
System Benchmarks Index Score (Partial Only) 10441.8
Regards,
Liangyan
On 2025/7/3 00:26, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2025 at 08:23:58PM +0800, Liangyan wrote:
>> We test that unixbench spawn has big improvement in Intel 8582c 120-CPU
>> guest vm if switch to qspinlock.
>
> And ARM or AMD?
>
>>
>> Command: ./Run -c 120 spawn
>>
>> Use virt_spin_lock:
>> System Benchmarks Partial Index BASELINE RESULT INDEX
>> Process Creation 126.0 71878.4 5704.6
>> ========
>> System Benchmarks Index Score (Partial Only) 5704.6
>>
>>
>> Use qspinlock:
>> System Benchmarks Partial Index BASELINE RESULT INDEX
>> Process Creation 126.0 173566.6 13775.1
>> ========
>> System Benchmarks Index Score (Partial Only 13775.1
>>
>>
>> Regards,
>> Liangyan
>>
>> On 2025/7/2 16:19, Bibo Mao wrote:
>>>
>>>
>>> On 2025/7/2 下午2:42, Liangyan wrote:
>>>> When KVM_HINTS_REALTIME is set and KVM_FEATURE_PV_UNHALT is clear,
>>>> currently guest will use virt_spin_lock.
>>>> Since KVM_HINTS_REALTIME is set, use native qspinlock should be safe
>>>> and have better performance than virt_spin_lock.
>>> Just be curious, do you have actual data where native qspinlock has
>>> better performance than virt_spin_lock()?
>>>
>>> By my understanding, qspinlock is not friendly with VM. When lock is
>>> released, it is acquired with one by one order in contending queue. If
>>> the first vCPU in contending queue is preempted, the other vCPUs can not
>>> get lock. On physical machine it is almost impossible that CPU
>>> contending lock is preempted.
>>>
>>> Regards
>>> Bibo Mao
>>>>
>>>> Signed-off-by: Liangyan <liangyan.peng@bytedance.com>
>>>> ---
>>>> arch/x86/kernel/kvm.c | 18 +++++++++---------
>>>> 1 file changed, 9 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
>>>> index 921c1c783bc1..9080544a4007 100644
>>>> --- a/arch/x86/kernel/kvm.c
>>>> +++ b/arch/x86/kernel/kvm.c
>>>> @@ -1072,6 +1072,15 @@ static void kvm_wait(u8 *ptr, u8 val)
>>>> */
>>>> void __init kvm_spinlock_init(void)
>>>> {
>>>> + /*
>>>> + * Disable PV spinlocks and use native qspinlock when dedicated
>>>> pCPUs
>>>> + * are available.
>>>> + */
>>>> + if (kvm_para_has_hint(KVM_HINTS_REALTIME)) {
>>>> + pr_info("PV spinlocks disabled with KVM_HINTS_REALTIME
>>>> hints\n");
>>>> + goto out;
>>>> + }
>>>> +
>>>> /*
>>>> * In case host doesn't support KVM_FEATURE_PV_UNHALT there is
>>>> still an
>>>> * advantage of keeping virt_spin_lock_key enabled:
>>>> virt_spin_lock() is
>>>> @@ -1082,15 +1091,6 @@ void __init kvm_spinlock_init(void)
>>>> return;
>>>> }
>>>> - /*
>>>> - * Disable PV spinlocks and use native qspinlock when dedicated
>>>> pCPUs
>>>> - * are available.
>>>> - */
>>>> - if (kvm_para_has_hint(KVM_HINTS_REALTIME)) {
>>>> - pr_info("PV spinlocks disabled with KVM_HINTS_REALTIME
>>>> hints\n");
>>>> - goto out;
>>>> - }
>>>> -
>>>> if (num_possible_cpus() == 1) {
>>>> pr_info("PV spinlocks disabled, single CPU\n");
>>>> goto out;
>>>>
>>>
>>
>>
next prev parent reply other threads:[~2025-07-04 6:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-02 6:42 [RFC] x86/kvm: Use native qspinlock by default when realtime hinted Liangyan
2025-07-02 8:19 ` Bibo Mao
2025-07-02 12:23 ` [External] " Liangyan
2025-07-02 16:26 ` Konrad Rzeszutek Wilk
2025-07-04 6:12 ` Liangyan [this message]
2025-07-05 6:39 ` Bibo Mao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dc4d14c5-1f04-47d7-b314-e4db62f57665@google.com \
--to=liangyan.peng@bytedance.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maobibo@loongson.cn \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.