From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC 1/2] Simulate Intel cpufreq MSRs in kvm guests to influencenice priority Date: Sun, 27 Jul 2008 11:27:22 +0300 Message-ID: <488C316A.50402@qumranet.com> References: <20080715231814.GE9465@tree.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: djwong@us.ibm.com, kvm@vger.kernel.org To: "Tian, Kevin" Return-path: Received: from il.qumranet.com ([212.179.150.194]:12100 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750982AbYG0I1X (ORCPT ); Sun, 27 Jul 2008 04:27:23 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Tian, Kevin wrote: >> From: Darrick J. Wong >> Sent: 2008=C4=EA7=D4=C216=C8=D5 7:18 >> >> I envision four scenarios: >> >> 0. Guests that don't know about cpufreq still run at whatever=20 >> nice level >> they started with. >> >> 1. If we have a system with a lot of idle VMs, they will all=20 >> run with +5 >> nice and this patch has no effect. >> >> 2. If we have a system with a lot of busy VMs, they all run=20 >> with -5 nice >> and this patch also has no effect. >> >> 3. If, however, we have a lot of idle VMs and a few busy ones, then = the >> -5 nice of the busy VMs will get those VMs extra CPU time. On a rea= lly >> crummy FPU microbenchmark I have, the score goes from about 500 to 2= 000 >> with the patch applied, though of course YMMV. In some respects thi= s >> =20 > > How many VMs did you run in this test? All the VMs are idle except > the one where your benchmark runs? > > How about the actual effect when several VMs are doing some stuff? > > There's another scenario where some VMs don't support cpufreq while > others do. Here is it unfair to just renice the latter when the forme= r is > not 'nice' at all? > =20 I guess the solution for such issues is not to have kvm (or qemu) play with nice levels, but instead send notifications on virtual frequency changes on the qemu monitor. The management application can then choose whether to ignore the information, play with nice levels, or even propagate the frequency change to the host (useful in client-side virtualization). --=20 error compiling committee.c: too many arguments to function