From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42187) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLanE-0002Zo-Gf for qemu-devel@nongnu.org; Mon, 16 Sep 2013 11:32:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VLan9-00041o-Gs for qemu-devel@nongnu.org; Mon, 16 Sep 2013 11:32:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29797) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLan9-000413-81 for qemu-devel@nongnu.org; Mon, 16 Sep 2013 11:32:47 -0400 Date: Mon, 16 Sep 2013 18:32:39 +0300 From: Gleb Natapov Message-ID: <20130916153239.GD906@redhat.com> References: <20130916121545.GH5105@irqsave.net> <8668D877-8B37-48E3-97B8-CE36DB884E54@suse.de> <20130916150544.GJ5105@irqsave.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20130916150544.GJ5105@irqsave.net> Subject: Re: [Qemu-devel] cpufreq and QEMU guests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?Q?Beno=C3=AEt?= Canet Cc: "peter.maydell@linaro.org" , "viresh.kumar@linaro.org" , Alexander Graf , "cpufreq@vger.kernel.org" , "qemu-devel@nongnu.org" , "rjw@sisk.pl" , "pbonzini@redhat.com" On Mon, Sep 16, 2013 at 05:05:45PM +0200, Beno=C3=AEt Canet wrote: > Le Monday 16 Sep 2013 =C3=A0 09:39:10 (-0500), Alexander Graf a =C3=A9cri= t : > >=20 > >=20 > > Am 16.09.2013 um 07:15 schrieb Beno=C3=AEt Canet : > >=20 > > >=20 > > > Hello, > > >=20 > > > I know a cloud provider worried about the fact that the /proc/cpuinfo= of his > > > guests give a bogus frequency to his customer. > > >=20 > > > QEMU and the guests kernel currently have no way to reflect the host = frequency > > > changes to the guests. > > >=20 > > > The customer compute intensive application then read this information= and take > > > wrong decisions. > >=20 > > Why do they care about the frequency? Is it for scheduling workloads? T= he only other case I can think of would be the TSC and that should be fixed= frequency these days. > >=20 > > If it's scheduling, you could maybe expose the unavailable compute time= as steal time to the guest. Exposibg frequency in a virtual environment fe= els backwards. >=20 > The final customer have a compute intensive workload. > At startup the code retrieve the cpu cache topology, the cpu model, and v= arious > informations including the guest cpu frequency before starting the comput= e job. > The QEMU instance typicaly use -cpu host. >=20 > The code inspects the cpu frequency has seen by the guests to choose the = number > of vms to instanciate to compute the given task. I am not sure I understand. They look at guest cpu frequency to estimate guest's performance? > They even destroy and recreate some vms that would be underperforming to > mitigate the high inter vm communication costs. >=20 > Do you think the steal time trick would work for this ? >=20 -- Gleb.