[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.