Messages in this thread | | | Date | Tue, 31 May 2022 17:51:47 +0200 | Subject | Re: ...\n | From | Paolo Bonzini <> |
| |
On 5/31/22 16:52, Durrant, Paul wrote: >> -----Original Message----- >> From: Peter Zijlstra <peterz@infradead.org> >> Sent: 31 May 2022 15:44 >> To: Allister, Jack <jalliste@amazon.com> >> Cc: bp@alien8.de; diapop@amazon.co.uk; hpa@zytor.com; jmattson@google.com; joro@8bytes.org; >> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; metikaya@amazon.co.uk; mingo@redhat.com; >> pbonzini@redhat.com; rkrcmar@redhat.com; sean.j.christopherson@intel.com; tglx@linutronix.de; >> vkuznets@redhat.com; wanpengli@tencent.com; x86@kernel.org >> Subject: RE: [EXTERNAL]...\n >> >> >> On Tue, May 31, 2022 at 02:02:36PM +0000, Jack Allister wrote: >>> The reasoning behind this is that you may want to run a guest at a >>> lower CPU frequency for the purposes of trying to match performance >>> parity between a host of an older CPU type to a newer faster one. >> >> That's quite ludicrus. Also, then it should be the host enforcing the >> cpufreq, not the guest. > > I'll bite... What's ludicrous about wanting to run a guest at a lower CPU freq to minimize observable change in whatever workload it is running?
Well, the right API is cpufreq, there's no need to make it a KVM functionality.
Paolo
| |