On 12/03/2010 03:38 AM, Avi Kivity wrote:
On 12/02/2010 05:23 PM, Anthony Liguori wrote:
On 12/02/2010 08:39 AM, lidong chen wrote:
In certain use-cases, we want to allocate guests fixed time slices
where idle
guest cycles leave the machine idling.
i could not understand why need this? can you tell more detailedly?
If you run 4 guests on a CPU, and they're all trying to consume 100%
CPU, all things being equal, you'll get ~25% CPU for each guest.
However, if one guest is idle, you'll get something like 1% 32% 33%
32%. This characteristic is usually desirable because it increase
aggregate throughput but in some circumstances, determinism is more
desirable than aggregate throughput.
This patch essentially makes guest execution non-work conserving by
making it appear to the scheduler that each guest wants 100% CPU even
though they may be idling.
That means that regardless of what each guest is doing, if you have
four guests on one CPU, each will get ~25% CPU[1].
What if one of the guest crashes qemu or invokes a powerdown?
Suddenly the others get 33% each (with 1% going to my secret round-up
account). Doesn't seem like a reliable way to limit cpu.
A guest shutting down is a macro event. Macro events are easy to track
and are logged by even the most naive management tools. Macro events
affecting performance are a workable problem. I agree, it would be
ideal to make them not impact performance but perfection is the enemy of
good.
The problem with the status quo is that there is no performance
stability in a consolidation environment.
Regards,
Anthony Liguori
--
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
