On 09/27/2009 04:53 PM, Joerg Roedel wrote:
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.
Only one runable task on each cpu is unlikely in a situation of high
vcpu overcommit (where pause filtering matters).
I think even 2:1 overcommit can degrade performance terribly.
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.
I agree that a directed yield with possible rebalance would be good to
have, but this is very intrusive to the scheduler code and I think we
should at least try if this simpler approach already gives us good
results.
No objection to trying. I'd like to see hrtimer sleep as a baseline
since it doesn't require any core changes, and we can play with it as we
add more core infrastructure:
- not sleeping if all vcpus are running
- true yield() instead of sleep
- directed yield
- cross cpu directed yield
--
error compiling committee.c: too many arguments to function
--
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
