qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] cpufreq and QEMU guests


From: Gleb Natapov
Subject: Re: [Qemu-devel] cpufreq and QEMU guests
Date: Mon, 16 Sep 2013 18:32:39 +0300

On Mon, Sep 16, 2013 at 05:05:45PM +0200, Benoît Canet wrote:
> Le Monday 16 Sep 2013 à 09:39:10 (-0500), Alexander Graf a écrit :
> > 
> > 
> > Am 16.09.2013 um 07:15 schrieb Benoît Canet <address@hidden>:
> > 
> > > 
> > > Hello,
> > > 
> > > I know a cloud provider worried about the fact that the /proc/cpuinfo of 
> > > his
> > > guests give a bogus frequency to his customer.
> > > 
> > > QEMU and the guests kernel currently have no way to reflect the host 
> > > frequency
> > > changes to the guests.
> > > 
> > > The customer compute intensive application then read this information and 
> > > take
> > > wrong decisions.
> > 
> > Why do they care about the frequency? Is it for scheduling workloads? The 
> > only other case I can think of would be the TSC and that should be fixed 
> > frequency these days.
> > 
> > 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 
> various
> informations including the guest cpu frequency before starting the compute 
> 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.
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.
> 
> Do you think the steal time trick would work for this ?
> 

--
                        Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]