On Fri, 2010-12-03 at 10:35 -0500, Rik van Riel wrote: > On 12/03/2010 10:09 AM, Mike Galbraith wrote: > > On Fri, 2010-12-03 at 09:48 -0500, Rik van Riel wrote: > >> On 12/03/2010 09:45 AM, Mike Galbraith wrote: > >> > >>> I'll have to go back and re-read that. Off the top of my head, I see no > >>> way it could matter which container the numbers live in as long as they > >>> keep advancing, and stay in the same runqueue. (hm, task weights would > >>> have to be the same too or scaled. dangerous business, tinkering with > >>> vruntimes) > >> > >> They're not necessarily in the same runqueue, the > >> VCPU that is given time might be on another CPU > >> than the one that was spinning on a lock. > > > > I don't think pumping vruntime cross cfs_rq would be safe, for the > > reason noted (et al). No competition means vruntime is meaningless. > > Donating just advances a clock that nobody's looking at. > > Do you have suggestions on what I should do to make > this yield_to functionality work? Hm. The problem with donating vruntime across queues is that there is no global clock. You have to be in the same frame of reference for vruntime donation to make any sense. Same with cross cpu yield_to() hw wise though. It makes no sense from another frame of reference. Pull. -Mike -- 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
