From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2) Date: Fri, 03 Dec 2010 11:38:33 +0200 Message-ID: <4CF8BA99.9070002@redhat.com> References: <1291298357-5695-1-git-send-email-aliguori@us.ibm.com> <4CF7B9FF.9000904@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lidong chen , kvm@vger.kernel.org, Marcelo Tosatti , Chris Wright , Srivatsa Vaddagiri To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:10000 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755801Ab0LCJio (ORCPT ); Fri, 3 Dec 2010 04:38:44 -0500 In-Reply-To: <4CF7B9FF.9000904@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 12/02/2010 05:23 PM, Anthony Liguori wrote: > On 12/02/2010 08:39 AM, lidong chen wrote: >> In certain use-cases, we want to allocate guests fixed time slices >> where idle >> guest cycles leave the machine idling. >> >> i could not understand why need this? can you tell more detailedly? > > If you run 4 guests on a CPU, and they're all trying to consume 100% > CPU, all things being equal, you'll get ~25% CPU for each guest. > > However, if one guest is idle, you'll get something like 1% 32% 33% > 32%. This characteristic is usually desirable because it increase > aggregate throughput but in some circumstances, determinism is more > desirable than aggregate throughput. > > This patch essentially makes guest execution non-work conserving by > making it appear to the scheduler that each guest wants 100% CPU even > though they may be idling. > > That means that regardless of what each guest is doing, if you have > four guests on one CPU, each will get ~25% CPU[1]. > What if one of the guest crashes qemu or invokes a powerdown? Suddenly the others get 33% each (with 1% going to my secret round-up account). Doesn't seem like a reliable way to limit cpu. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.