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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
