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 23:06:20 +0530 Message-ID: <20101203173619.GC13515@linux.vnet.ibm.com> References: <1291298357-5695-1-git-send-email-aliguori@us.ibm.com> <20101202191416.GQ10050@sequoia.sous-sol.org> <20101203115752.GD27994@linux.vnet.ibm.com> <20101203172825.GC10050@sequoia.sous-sol.org> Reply-To: vatsa@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Liguori , kvm@vger.kernel.org, Avi Kivity , Marcelo Tosatti To: Chris Wright Return-path: Received: from e37.co.us.ibm.com ([32.97.110.158]:56311 "EHLO e37.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753625Ab0LCRgZ (ORCPT ); Fri, 3 Dec 2010 12:36:25 -0500 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id oB3HY6UU032651 for ; Fri, 3 Dec 2010 10:34:06 -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 oB3HaOZA045080 for ; Fri, 3 Dec 2010 10:36:24 -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 oB3HaMMB030178 for ; Fri, 3 Dec 2010 10:36:23 -0700 Content-Disposition: inline In-Reply-To: <20101203172825.GC10050@sequoia.sous-sol.org> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Dec 03, 2010 at 09:28:25AM -0800, Chris Wright wrote: > * Srivatsa Vaddagiri (vatsa@linux.vnet.ibm.com) wrote: > > On Thu, Dec 02, 2010 at 11:14:16AM -0800, 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. > > > > That's not sufficient. Lets we have 3 guests A, B, C that need to be > > rate limited to 25% on a single cpu system. We create this idle guest > > D that is 100% cpu hog as per above definition. Now when one of the > > guest is idle, what ensures that the idle cycles of A is given only > > to D and not partly to B/C? > > Yeah, I pictured priorties handling this. All guest are of equal priorty in this case (that's how we are able to divide time into 25% chunks), so unless we dynamically boost D's priority based on how idle other VMs are, its not going to be easy! - vatsa