Re: ...\n

From: David Woodhouse <dwmw2@infradead.org>
To: Peter Zijlstra <peterz@infradead.org>,
	"Durrant, Paul" <pdurrant@amazon.co.uk>
Cc: "Allister, Jack" <jalliste@amazon.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"diapop@amazon.co.uk" <diapop@amazon.co.uk>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"jmattson@google.com" <jmattson@google.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"metikaya@amazon.co.uk" <metikaya@amazon.co.uk>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"rkrcmar@redhat.com" <rkrcmar@redhat.com>,
	"sean.j.christopherson@intel.com"
	<sean.j.christopherson@intel.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"vkuznets@redhat.com" <vkuznets@redhat.com>,
	"wanpengli@tencent.com" <wanpengli@tencent.com>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: ...\n
Date: Wed, 01 Jun 2022 14:14:42 +0100	[thread overview]
Message-ID: <cb5c7c4f1c403d0cdb9c95f8a258ee2d402d8314.camel@infradead.org> (raw)
In-Reply-To: <YpcMw2TgNWzrcoRm@worktop.programming.kicks-ass.net>

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

On Wed, 2022-06-01 at 08:52 +0200, Peter Zijlstra wrote:
> On Tue, May 31, 2022 at 02:52:04PM +0000, Durrant, Paul wrote:
> > > 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.
> 

Nah, lots of customers have existing workloads and they want them to
run the *same*. They don't want them to run *faster* because that could
expose existing bugs and race conditions in guest code that has worked
perfectly fine for years. They don't want us to stress-test it when it
was working fine before.

Hell, we are implementing guest transparent live migration to KVM from
*actual* Xen in order to let stuff "just continue to run as it did
before", when for many it would "just" be a case of rebuilding their
guest with new NVMe and network drivers.

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

It's actually the other way round. The older instance types were more
expensive; prices generally went down over time, especially $/perf.

None of that eliminates customer inertia.

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

No, but you can bring the performance envelope within spitting
distance. This isn't about hiding the fact that they are now running on
Linux and on newer CPUs; it's about not *breaking* things too much.

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

Not sure about that. I thought I saw analysis that something like the
last 5% of turbo performance cost 30% of the power budget in practice.

And running these Xen guests even scaled down on modern hardware is
still much more power efficient than running them on the original
hardware that we're migrating them from.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]