On 09/27/2009 04:07 PM, Joerg Roedel wrote:
On Sun, Sep 27, 2009 at 03:47:55PM +0200, Avi Kivity wrote:
On 09/27/2009 03:46 PM, Joerg Roedel wrote:
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?
yield() is a no-op in CFS.
Hmm, true. At least when kernel.sched_compat_yield == 0, which it is on my
distro.
If the scheduler would give us something like a real_yield() function
which asumes kernel.sched_compat_yield = 1 might help. At least its
better than sleeping for some random amount of time.
Depends. If it's a global yield(), yes. If it's a local yield() that
doesn't rebalance the runqueues we might be left with the spinning task
re-running.
Also, if yield means "give up the reminder of our timeslice", then we
potentially end up sleeping a much longer random amount of time. If we
yield to another vcpu in the same guest we might not care, but if we
yield to some other guest we're seriously penalizing ourselves.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
