Re: [RFC 1/2] Simulate Intel cpufreq MSRs in kvm guests to influencenice priority

[Avi Kivity <avi@qumranet.com>]

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).

-- 
error compiling committee.c: too many arguments to function