On 12/02/2010 02:40 PM, Marcelo Tosatti wrote:
On Thu, Dec 02, 2010 at 11:14:16AM -0800, Chris Wright wrote:
* Anthony Liguori (aligu...@us.ibm.com) 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();
}
This looked nice but the implementation in practice wasn't unless I
totally misunderstood what you were getting at.
default_idle() is not exported to modules and is not an interface meant
to be called directly. Plus, an idle loop like this delays the guest
until the scheduler wants to run something else but it doesn't account
for another thread trying to inject an event into the halting thread.
It's not immediately clear to me how to have what's effectively a wait
queue that hlts instead of calls the scheduler. You could mess around
with various signalling mechanisms but it gets ugly fast.
So I circled back to disabling hlt exiting this time taking care of
updating GUEST_ACTIVITY_STATE when necessary.
Regards,
Anthony Liguori
But you agree this is no KVM business.
--
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
--
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
