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: Thu, 02 Dec 2010 14:25:50 -0600 Message-ID: <4CF800CE.6080403@codemonkey.ws> References: <1291298357-5695-1-git-send-email-aliguori@us.ibm.com> <20101202191416.GQ10050@sequoia.sous-sol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Avi Kivity , Marcelo Tosatti , Srivatsa Vaddagiri To: Chris Wright Return-path: Received: from mail-qy0-f181.google.com ([209.85.216.181]:59662 "EHLO mail-qy0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753044Ab0LBUZx (ORCPT ); Thu, 2 Dec 2010 15:25:53 -0500 Received: by qyk12 with SMTP id 12so10793722qyk.19 for ; Thu, 02 Dec 2010 12:25:53 -0800 (PST) In-Reply-To: <20101202191416.GQ10050@sequoia.sous-sol.org> Sender: kvm-owner@vger.kernel.org List-ID: On 12/02/2010 01:14 PM, 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. > That's an interesting idea. I think Vatsa had some ideas about how to do this with existing mechanisms. I'm interesting in comparing behavior with fixed allocation because one thing the above relies upon is that the filler VM loses it's time when one of the non-filler VCPU needs to run. This may all work correctly but I think it's easier to rationalize about having each non-filler VCPU have a fixed (long) time slice. If a VCPU needs to wake up to become non-idle, it can do so immediately because it already has the PCPU. Regards, Anthony Liguori > What do you think? > > 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 >