* Anthony Liguori (anthony@xxxxxxxxxxxxx) wrote:
> On 12/03/2010 11:58 AM, Chris Wright wrote:
> >* Srivatsa Vaddagiri (vatsa@xxxxxxxxxxxxxxxxxx) wrote:
> >>On Fri, Dec 03, 2010 at 09:29:06AM -0800, Chris Wright wrote:
> >>>That's what Marcelo's suggestion does w/out a fill thread.
> >>There's one complication though even with that. How do we compute the
> >>real utilization of VM (given that it will appear to be burning 100% cycles)?
> >>We need to have scheduler discount the cycles burnt post halt-exit, so more
> >>stuff is needed than those simple 3-4 lines!
> >Heh, was just about to say the same thing ;)
>
> My first reaction is that it's not terribly important to account the
> non-idle time in the guest because of the use-case for this model.
Depends on the chargeback model. This would put guest vcpu runtime vs
host running guest vcpu time really out of skew. ('course w/out steal
and that time it's already out of skew). But I think most models are
more uptime based rather then actual runtime now.
> Eventually, it might be nice to have idle time accounting but I
> don't see it as a critical feature here.
>
> Non-idle time simply isn't as meaningful here as it normally would
> be. If you have 10 VMs in a normal environment and saw that you had
> only 50% CPU utilization, you might be inclined to add more VMs.
Who is "you"? cloud user, or cloud service provider's scheduler?
On the user side, 50% cpu utilization wouldn't trigger me to add new
VMs. On the host side, 50% cpu utilization would have to be measure
solely in terms of guest vcpu count.
> But if you're offering deterministic execution, it doesn't matter if
> you only have "50%" utilization. If you add another VM, the guests
> will get exactly the same impact as if they were using 100%
> utilization.
Sorry, didn't follow here?
thanks,
-chris
--
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
