On Mon, Sep 16, 2013 at 05:46:04PM +0200, Benoît Canet wrote: > Le Monday 16 Sep 2013 à 18:32:39 (+0300), Gleb Natapov a écrit : > > 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 <benoit.canet@xxxxxxxxxxx>: > > > > > > > > > > > > > > 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? > > Yes they take guest cpu count, model and frequency to estimate the performance > of the guest. > Next they cluster enough guests to be able to compute the job in a given time by > using this estimate. > They do it wrong. They should take guest cpu count, host cpu model and frequency, pcpu/vcpu over commit (if any), guest/host memory overcommit (if any) and estimate performance based on this. For pure computational performance guest core performance should be close to host core performance if there is not cpu/memory overcommit. With a lot of IO things become more complicated. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
