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:13:17 +0530 Message-ID: <20101203174317.GD13515@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> <20101203173619.GC13515@linux.vnet.ibm.com> <20101203173805.GE10050@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 e2.ny.us.ibm.com ([32.97.182.142]:33357 "EHLO e2.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751168Ab0LCRnd (ORCPT ); Fri, 3 Dec 2010 12:43:33 -0500 Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oB3HQRSL014629 for ; Fri, 3 Dec 2010 12:27:02 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id CCEEB728059 for ; Fri, 3 Dec 2010 12:43:30 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oB3HhUZS165662 for ; Fri, 3 Dec 2010 12:43:30 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oB3HhTmU001448 for ; Fri, 3 Dec 2010 15:43:30 -0200 Content-Disposition: inline In-Reply-To: <20101203173805.GE10050@sequoia.sous-sol.org> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Dec 03, 2010 at 09:38:05AM -0800, Chris Wright wrote: > > 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! > > Right, I think there has to be an external mgmt entity. Because num > vcpus is not static. So priorities have to be rebalanaced at vcpu > create/destroy time. and at idle/non-idle time as well, which makes the mgmt entity's job rather harder? Anyway, if we are willing to take a patch to burn cycles upon halt (as per Marcello's patch), that's be the best (short-term) solution ..otherwise, something like a filler-thread per-vcpu is more easier than dynamic change of priorities .. - vatsa