* Anthony Liguori (anthony@codemonkey.ws) wrote:
quoted text
> On 12/03/2010 11:58 AM, Chris Wright wrote:
> >* Srivatsa Vaddagiri (vatsa@linux.vnet.ibm.com) 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.

quoted text
> 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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html