Re: [External] Re: [RFC] x86/kvm: Use native qspinlock by default when realtime hinted

[Bibo Mao]

There is big improvement with the test result. spawn test case is a 
little tricky, if forked child process is scheduled on the same CPU with 
the parent, the benefit is very huge. I doubt it is probably caused by 
scheduler rather than by spinlock itself.

1. What is cpu topology and numa information with physical machine and 
virtual machine?

2. Could you show reschedule IPI interrupt stat information when running 
 spawn test case?

3. Could you run this case on CPU over-commit scenary, such as both two 
VMs with 120 vCPUs?

Regards
Bibo Mao


On 2025/7/2 下午8:23, Liangyan wrote:
> We test that unixbench spawn has big improvement in Intel 8582c 120-CPU 
> guest vm if switch to qspinlock.
>
> 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@xxxxxxxxxxxxx>
> > > ---
> > >   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;