On Thu, Dec 09, 2010 at 11:34:46PM -0500, Rik van Riel wrote: > On 12/03/2010 09:06 AM, Srivatsa Vaddagiri wrote: > >On Fri, Dec 03, 2010 at 03:03:30PM +0100, Peter Zijlstra wrote: > >>No, because they do receive service (they spend some time spinning > >>before being interrupted), so the respective vruntimes will increase, at > >>some point they'll pass B0 and it'll get scheduled. > > > >Is that sufficient to ensure that B0 receives its fair share (1/3 cpu in this > >case)? > > I have a rough idea for a simpler way to ensure > fairness. > > At yield_to time, we could track in the runqueue > structure that a task received CPU time (and on > the other runqueue that a task donated CPU time). > > The balancer can count time-given-to CPUs as > busier, and donated-time CPUs as less busy, > moving tasks away in the unlikely event that > the same task gets keeping CPU time given to > it. I think just capping donation (either on send side or receive side) may be more simpler here than to mess with load balancer logic. > Conversely, it can move other tasks onto CPUs > that have tasks on them that cannot make progress > right now and are just donating their CPU time. > > Most of the time the time-given and time-received > should balance out and there should be little to > no influence on the load balancer. This code would > just be there to deal with exceptional circumstances, > to avoid the theoretical worst case people have > described. - vatsa -- 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
