* Marcelo Tosatti (mtosatti@xxxxxxxxxx) wrote:
> On Thu, Dec 02, 2010 at 11:14:16AM -0800, Chris Wright wrote:
> > * Anthony Liguori (aliguori@xxxxxxxxxx) wrote:
> > > In certain use-cases, we want to allocate guests fixed time slices where idle
> > > guest cycles leave the machine idling. There are many approaches to achieve
> > > this but the most direct is to simply avoid trapping the HLT instruction which
> > > lets the guest directly execute the instruction putting the processor to sleep.
> >
> > I like the idea, esp to keep from burning power.
> >
> > > Introduce this as a module-level option for kvm-vmx.ko since if you do this
> > > for one guest, you probably want to do it for all. A similar option is possible
> > > for AMD but I don't have easy access to AMD test hardware.
> >
> > Perhaps it should be a VM level option. And then invert the notion.
> > Create one idle domain w/out hlt trap. Give that VM a vcpu per pcpu
> > (pin in place probably). And have that VM do nothing other than hlt.
> > Then it's always runnable according to scheduler, and can "consume" the
> > extra work that CFS wants to give away.
> >
> > What do you think?
> >
> > thanks,
> > -chris
>
> Consuming the timeslice outside guest mode is less intrusive and easier
> to replace. Something like this should work?
>
> if (vcpu->arch.mp_state == KVM_MP_STATE_HALTED) {
> while (!need_resched())
> default_idle();
> }
>
> But you agree this is no KVM business.
Like non-trapping hlt, that too will guarantee that the guest is preempted
by timeslice exhaustion (and is simpler than non-trapping hlt). So it
may well be the simplest for the case where we are perfectly committed
(i.e. the vcpu fractional core count totals the pcpu count). But once
we are undercommitted we still need some extra logic to handle the hard
cap and something to kick the running guest off the cpu and suck up the
extra cycles in a power conserving way.
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
