From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2) Date: Fri, 03 Dec 2010 16:49:20 -0600 Message-ID: <4CF973F0.7010409@codemonkey.ws> References: <1291298357-5695-1-git-send-email-aliguori@us.ibm.com> <20101202191416.GQ10050@sequoia.sous-sol.org> <20101202204016.GB31316@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Wright , kvm@vger.kernel.org, Avi Kivity , Srivatsa Vaddagiri To: Marcelo Tosatti Return-path: Received: from mail-yx0-f174.google.com ([209.85.213.174]:52220 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751582Ab0LCWtd (ORCPT ); Fri, 3 Dec 2010 17:49:33 -0500 Received: by yxt3 with SMTP id 3so4564566yxt.19 for ; Fri, 03 Dec 2010 14:49:33 -0800 (PST) In-Reply-To: <20101202204016.GB31316@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: 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 (aliguori@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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >