On Sun, Sep 27, 2009 at 10:31:21AM +0200, Avi Kivity wrote: > On 09/25/2009 11:43 PM, Joerg Roedel wrote: >> On Wed, Sep 23, 2009 at 05:09:38PM +0300, Avi Kivity wrote: >> >>> We haven't sorted out what is the correct thing to do here. I think we >>> should go for a directed yield, but until we have it, you can use >>> hrtimers to sleep for 100 microseconds and hope the holding vcpu will >>> get scheduled. Even if it doesn't, we're only wasting a few percent cpu >>> time instead of spinning. >>> >> How do you plan to find out to which vcpu thread the current thread >> should yield? >> > > We can't find exactly which vcpu, but we can: > > - rule out threads that are not vcpus for this guest > - rule out threads that are already running > > A major problem with sleep() is that it effectively reduces the vm > priority relative to guests that don't have spinlock contention. By > selecting a random nonrunnable vcpu belonging to this guest, we at least > preserve the guest's timeslice. Ok, that makes sense. But before trying that we should probably try to call just yield() instead of schedule()? I remember someone from our team here at AMD did this for Xen a while ago and already had pretty good results with that. Xen has a completly other scheduler but maybe its worth trying? Joerg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
