From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLaLO-0004FL-N4 for qemu-devel@nongnu.org; Mon, 16 Sep 2013 11:04:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VLaLI-0002Jb-Ly for qemu-devel@nongnu.org; Mon, 16 Sep 2013 11:04:06 -0400 Received: from nodalink.pck.nerim.net ([62.212.105.220]:36032 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLaLI-0002JO-BE for qemu-devel@nongnu.org; Mon, 16 Sep 2013 11:04:00 -0400 Date: Mon, 16 Sep 2013 17:05:45 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20130916150544.GJ5105@irqsave.net> References: <20130916121545.GH5105@irqsave.net> <8668D877-8B37-48E3-97B8-CE36DB884E54@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <8668D877-8B37-48E3-97B8-CE36DB884E54@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] cpufreq and QEMU guests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , "peter.maydell@linaro.org" , "gleb@redhat.com" , "viresh.kumar@linaro.org" , "qemu-devel@nongnu.org" , "cpufreq@vger.kernel.org" , "rjw@sisk.pl" , "pbonzini@redhat.com" Le Monday 16 Sep 2013 =E0 09:39:10 (-0500), Alexander Graf a =E9crit : >=20 >=20 > Am 16.09.2013 um 07:15 schrieb Beno=EEt 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 fix= ed 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 = feels backwards. 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. The code inspects the cpu frequency has seen by the guests to choose the = number of vms to instanciate to compute the given task. They even destroy and recreate some vms that would be underperforming to mitigate the high inter vm communication costs. Do you think the steal time trick would work for this ? Best regards Beno=EEt >=20 > Alex >=20 > >=20 > > I looked at the various Linux cpufreq drivers and they all seems to b= e table > > based. Is it true ? > >=20 > > For example the acpi cpufreq driver have 16 differents pstates at han= d to lookup > > in the pstate table and get the frequency. > >=20 > > Given that guests can migrate from one hardware to a slightly differe= nt hardware > > the table may become wrong after live migration. > >=20 > > What would be the best hardware to emulate in order to pass an arbitr= ary > > frequency to the guest ? > >=20 > > Would a pvfreq paravirtualized QEMU hardware and a guest driver imple= menting > > only the callbacks needed to read the frequency be a good idea ? > >=20 > > Best regards > >=20 > > Beno=EEt > >=20 > > ps: > > I CC this mail to the other QEMU arch maintainers because the problem= must be > > the same everywhere where KVM run. > -- > To unsubscribe from this list: send the line "unsubscribe cpufreq" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html