On 12/13/2010 02:39 PM, Balbir Singh wrote:
* Avi Kivity<avi@xxxxxxxxxx> [2010-12-13 13:57:37]: > On 12/11/2010 03:57 PM, Balbir Singh wrote: > >* Avi Kivity<avi@xxxxxxxxxx> [2010-12-11 09:31:24]: > > > >> On 12/10/2010 07:03 AM, Balbir Singh wrote: > >> >> > >> >> Scheduler people, please flame me with anything I may have done > >> >> wrong, so I can do it right for a next version :) > >> >> > >> > > >> >This is a good problem statement, there are other things to consider > >> >as well > >> > > >> >1. If a hard limit feature is enabled underneath, donating the > >> >timeslice would probably not make too much sense in that case > >> > >> What's the alternative? > >> > >> Consider a two vcpu guest with a 50% hard cap. Suppose the workload > >> involves ping-ponging within the guest. If the scheduler decides to > >> schedule the vcpus without any overlap, then the throughput will be > >> dictated by the time slice. If we allow donation, throughput is > >> limited by context switch latency. > >> > > > >If the vpcu holding the lock runs more and capped, the timeslice > >transfer is a heuristic that will not help. > > Why not? as long as we shift the cap as well. > Shifting the cap would break it, no?
The total cap for the guest would remain.
Anyway, that is something for us to keep track of as we add additional heuristics, not a show stopper.
Sure, as long as we see a way to fix it eventually. -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
