>From: Avi Kivity [mailto:[EMAIL PROTECTED] >Sent: 2008年7月27日 16:27 > >Tian, Kevin wrote: >>> From: Darrick J. Wong >>> Sent: 2008年7月16日 7:18 >>> >>> I envision four scenarios: >>> >>> 0. Guests that don't know about cpufreq still run at whatever >>> nice level >>> they started with. >>> >>> 1. If we have a system with a lot of idle VMs, they will all >>> run with +5 >>> nice and this patch has no effect. >>> >>> 2. If we have a system with a lot of busy VMs, they all run >>> with -5 nice >>> and this patch also has no effect. >>> >>> 3. If, however, we have a lot of idle VMs and a few busy >ones, then the >>> -5 nice of the busy VMs will get those VMs extra CPU time. >On a really >>> crummy FPU microbenchmark I have, the score goes from about >500 to 2000 >>> with the patch applied, though of course YMMV. In some >respects this >>> >> >> How many VMs did you run in this test? All the VMs are idle except >> the one where your benchmark runs? >> >> How about the actual effect when several VMs are doing some stuff? >> >> There's another scenario where some VMs don't support cpufreq while >> others do. Here is it unfair to just renice the latter when >the former is >> not 'nice' at all? >> > >I guess the solution for such issues is not to have kvm (or qemu) play >with nice levels, but instead send notifications on virtual frequency >changes on the qemu monitor. The management application can then choose >whether to ignore the information, play with nice levels, or even >propagate the frequency change to the host (useful in client-side >virtualization). >
Yes, that'd be more flexible and cleaner. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
