Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2)

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/02/2010 09:44 PM, Chris Wright wrote:
>> Yes.
>>
>> There's definitely a use-case to have a hard cap.
>>      
> OK, good, just wanted to be clear.  Because this started as a discussion
> of hard caps, and it began to sound as if you were no longer advocating
> for them.
>
>    
>> But I think another common use-case is really just performance
>> isolation.  If over the course of a day, you go from 12CU, to 6CU,
>> to 4CU, that might not be that bad of a thing.
>>      
> I guess it depends on your SLA.  We don't have to do anything to give
> varying CU based on host load.  That's the one thing CFS will do for
> us quite well ;)
>    

I'm really anticipating things like the EC2 micro instance where the CPU 
allotment is variable.  Variable allotments are interesting from a 
density perspective but having interdependent performance is definitely 
a problem.

Another way to think about it: a customer reports a performance problem 
at 1PM.  With non-yielding guests, you can look at logs and see that the 
expected capacity was 2CU (it may have changed to 4CU at 3PM).  However, 
without something like non-yielding guests, the performance is almost 
entirely unpredictable and unless you have an exact timestamp from the 
customer along with a fine granularity performance log, there's no way 
to determine whether it's expected behavior.

>> If the environment is designed correctly, of N nodes, N-1 will
>> always be at capacity so it's really just a single node hat is under
>> utilized.
>>      
> Many clouds do a variation on Small, Medium, Large sizing.  So depending
> on the scheduler (best fit, rr...) even the notion of at capacity may
> change from node to node and during the time of day.
>    

An ideal cloud will make sure that something like 4 Small == 2 Medium == 
1 Large instance and that the machine capacity is always a multiple of 
Large instance size.

With a division like this, you can always achieve maximum density 
provided that you can support live migration.

Regards,

Anthony Liguori


> thanks,
> -chris
>