Re: [Xen-devel] [PATCH RFC v5 4/8] pvqspinlock, x86: Allow unfair spinlock in a real PV environment

[Paolo Bonzini <pbonzini@xxxxxxxxxx>]

Il 28/02/2014 18:06, Waiman Long ha scritto:
> On 02/26/2014 12:07 PM, Konrad Rzeszutek Wilk wrote:
> > On Wed, Feb 26, 2014 at 10:14:24AM -0500, Waiman Long wrote:
> > > Locking is always an issue in a virtualized environment as the virtual
> > > CPU that is waiting on a lock may get scheduled out and hence block
> > > any progress in lock acquisition even when the lock has been freed.
> > >
> > > One solution to this problem is to allow unfair lock in a
> > > para-virtualized environment. In this case, a new lock acquirer can
> > > come and steal the lock if the next-in-line CPU to get the lock is
> > > scheduled out. Unfair lock in a native environment is generally not a
> > Hmm, how do you know if the 'next-in-line CPU' is scheduled out? As
> > in the hypervisor knows - but you as a guest might have no idea
> > of it.
> I use a heart-beat counter to see if the other side responses within a
> certain time limit. If not, I assume it has been scheduled out probably
> due to PLE.
PLE is unnecessary if you have "true" pv spinlocks where the 
next-in-line schedules itself out with a hypercall (Xen) or hlt 
instruction (KVM).  Set a bit in the qspinlock before going to sleep, 
and the lock owner will know that it needs to kick the next-in-line.
I think there is no need for the unfair lock bits.  1-2% is a pretty 
large hit.
Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel