[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABgObfYYUNb_pEVA2xdUm_U39Wc1=AahJKDx2=9P+aK5=z202w@mail.gmail.com>
Date: Tue, 31 May 2022 16:52:56 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Jack Allister <jalliste@...zon.com>,
Borislav Petkov <bp@...en8.de>, diapop@...zon.co.uk,
"Anvin, H. Peter" <hpa@...or.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>, kvm <kvm@...r.kernel.org>,
"Kernel Mailing List, Linux" <linux-kernel@...r.kernel.org>,
Metin Kaya <metikaya@...zon.co.uk>,
Ingo Molnar <mingo@...hat.com>,
Radim Krcmar <rkrcmar@...hat.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
"the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: ...\n
On Tue, May 31, 2022 at 4:45 PM Peter Zijlstra <peterz@...radead.org> 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.
It is a weird usecase indeed, but actually it *is* enforced by the
host in Jack's patch.
On the other hand doing it by writing random MSRs, with no save and
load when the task is scheduled or migrated, will not fly outside
Amazon datacenters. The patch also has traces of the Amazon kernel and
doesn't apply upstream.
Paolo
Powered by blists - more mailing lists