Re: ...\n

[Peter Zijlstra]

On Tue, May 31, 2022 at 02:52:04PM +0000, Durrant, Paul wrote:
> > -----Original Message-----
> > From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > Sent: 31 May 2022 15:44
> > To: Allister, Jack <jalliste@xxxxxxxxxx>
> > Cc: bp@xxxxxxxxx; diapop@xxxxxxxxxxxx; hpa@xxxxxxxxx; jmattson@xxxxxxxxxx; joro@xxxxxxxxxx;
> > kvm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; metikaya@xxxxxxxxxxxx; mingo@xxxxxxxxxx;
> > pbonzini@xxxxxxxxxx; rkrcmar@xxxxxxxxxx; sean.j.christopherson@xxxxxxxxx; tglx@xxxxxxxxxxxxx;
> > vkuznets@xxxxxxxxxx; wanpengli@xxxxxxxxxxx; x86@xxxxxxxxxx
> > 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?

*why* would you want to do that? Everybody wants their stuff done
faster.

If this is some hare-brained money scheme; must not give them if they
didn't pay up then I really don't care.

On top of that, you can't hide uarch differences with cpufreq capping.

Also, it is probably more power efficient to let it run faster and idle
more, so you're not being environmental either.