From mboxrd@z Thu Jan 1 00:00:00 1970 From: Srivatsa Vaddagiri Subject: Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2) Date: Fri, 3 Dec 2010 16:51:59 +0530 Message-ID: <20101203112159.GC27994@linux.vnet.ibm.com> References: <1291298357-5695-1-git-send-email-aliguori@us.ibm.com> <20101202191416.GQ10050@sequoia.sous-sol.org> <4CF8BB0B.40809@redhat.com> Reply-To: vatsa@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Chris Wright , Anthony Liguori , kvm@vger.kernel.org, Marcelo Tosatti To: Avi Kivity Return-path: Received: from e35.co.us.ibm.com ([32.97.110.153]:48840 "EHLO e35.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932465Ab0LCLWE (ORCPT ); Fri, 3 Dec 2010 06:22:04 -0500 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id oB3B9rJC025698 for ; Fri, 3 Dec 2010 04:09:53 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oB3BM394090386 for ; Fri, 3 Dec 2010 04:22:03 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oB3BM1vJ020867 for ; Fri, 3 Dec 2010 04:22:03 -0700 Content-Disposition: inline In-Reply-To: <4CF8BB0B.40809@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Dec 03, 2010 at 11:40:27AM +0200, Avi Kivity wrote: > On 12/02/2010 09:14 PM, Chris Wright wrote: > >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's the difference between this and the Linux idle threads? If we have 3 VMs and want to give them 25% each of a CPU, then having just idle thread would end up giving them 33%. One way of achieving 25% rate limit is to create a "dummy" or "filler" VM, and let it compete for resource, thus rate-limiting everyone to 25% in this case. Essentially we are tackling rate-limit problem by creating additional "filler" VMs/threads that will compete for resource, thus keeping in check how much cpu resource is consumed by "real" VMs. Admittedly not as neat as having a in-kernel support for rate-limit. - vatsa