RE: [????] RE: [PATCH RESEND^2] x86/paravirt: add backoff mechanism to virt_spin_lock

[Li,Rongqing]

> On 8/13/2025 10:33 PM, Peter Zijlstra wrote:
> > On Wed, Aug 13, 2025 at 08:50:43AM +0800, Wangyang Guo wrote:
> >> When multiple threads waiting for lock at the same time, once lock
> >> owner releases the lock, waiters will see lock available and all try
> >> to lock, which may cause an expensive CAS storm.
> >>
> >> Binary exponential backoff is introduced. As try-lock attempt
> >> increases, there is more likely that a larger number threads compete
> >> for the same lock, so increase wait time in exponential.
> >
> > You shouldn't be using virt_spin_lock() to begin with. That means
> > you've misconfigured your guest.
> >
> > We have paravirt spinlocks for a reason.
> 
> We have tried PARAVIRT_SPINLOCKS, it can help to reduce the contention cycles,
> but the throughput is not good. I think there are two factors:
> 
> 1. the VM is not overcommit, each thread has its CPU resources to doing spin
> wait.

If vm is not overcommit, guest should have KVM_HINTS_REALTIME, I think native qspinlock should be better
Could you try test this patch
https://patchwork.kernel.org/project/kvm/patch/20250722110005.4988-1-lirongqing@xxxxxxxxx/


Furthermore, I think the virt_spin_lock needs to be optimized.

Br
-Li

> 2. the critical section is very short; spin wait is faster than pv_kick.
> 
> BR
> Wangyang