Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support for KVM guests

[Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>]

On 01/17/2012 05:29 AM, Jeremy Fitzhardinge wrote:
> On 01/16/2012 07:55 PM, Avi Kivity wrote:
> > On 01/16/2012 08:40 AM, Jeremy Fitzhardinge wrote:
> > > > That means we're spinning for n cycles, then notify the spinlock holder that 
> > > > we'd like to get kicked and go sleeping. While I'm pretty sure that it improves 
> > > > the situation, it doesn't solve all of the issues we have.
> > > >
> > > > Imagine we have an idle host. All vcpus can freely run and everyone can fetch 
> > > > the lock as fast as on real machines. We don't need to / want to go to sleep 
> > > > here. Locks that take too long are bugs that need to be solved on real hw just 
> > > > as well, so all we do is possibly incur overhead.
> > > I'm not quite sure what your concern is.  The lock is under contention, so 
> > > there's nothing to do except spin; all this patch adds is a variable 
> > > decrement/test to the spin loop, but that's not going to waste any more CPU 
> > > than the non-counting case.  And once it falls into the blocking path, its a 
> > > win because the VCPU isn't burning CPU any more.
> > The wakeup path is slower though.  The previous lock holder has to
> > hypercall, and the new lock holder has to be scheduled, and transition
> > from halted state to running (a vmentry).  So it's only a clear win if
> > we can do something with the cpu other than go into the idle loop.
> Not burning power is a win too.
>
> Actually what you want is something like "if you preempt a VCPU while
> its spinning in a lock, then push it into the slowpath and don't
> reschedule it without a kick".  But I think that interface would have a
> lot of fiddly corners.
Yes wakeup path is little slower but better than burning cpu. no?

Suppose we have  16 vcpu,
vcpu 1- lockholder (preempted).
vcpu 2-8 - in slowpath.

If scheduler schedules vcpu-1 that is most favourable for lock progress,
But if vcpu-9 - vcpu-16 OR something else scheduled, then  also it's a 
win right (we are doing some useful work), but yes lock progress is
again little slower though.

The optimization areas of interests are perhaps:
(1) suppose vcpu-1 is running and is about to release lock and next
vcpu in queue just goes to halt(). so this makes us to tune 
SPIN_THRESHOLD rightly and have a mechanism to determine if lock-holder 
is running and do continue spin. Identifying whether lock-holder is 
running would be easier task and can be next step of optimization.
(2) Much talked, identifying lockholder-preemption (vcpu) and do
yield_to().

But I am not sure how complicated is yield_to() implementation once we 
have identified the exact preempted vcpu (lock-holder).
>      J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel