linux-kernel - Re: ...\n

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YpcMw2TgNWzrcoRm@worktop.programming.kicks-ass.net>
Date:   Wed, 1 Jun 2022 08:52:51 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Durrant, Paul" <pdurrant@...zon.co.uk>
Cc:     "Allister, Jack" <jalliste@...zon.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "diapop@...zon.co.uk" <diapop@...zon.co.uk>,
        "hpa@...or.com" <hpa@...or.com>,
        "jmattson@...gle.com" <jmattson@...gle.com>,
        "joro@...tes.org" <joro@...tes.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "metikaya@...zon.co.uk" <metikaya@...zon.co.uk>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "rkrcmar@...hat.com" <rkrcmar@...hat.com>,
        "sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "wanpengli@...cent.com" <wanpengli@...cent.com>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: ...\n

On Tue, May 31, 2022 at 02:52:04PM +0000, Durrant, Paul wrote:
> > -----Original Message-----
> > From: Peter Zijlstra <peterz@...radead.org>
> > Sent: 31 May 2022 15:44
> > To: Allister, Jack <jalliste@...zon.com>
> > Cc: bp@...en8.de; diapop@...zon.co.uk; hpa@...or.com; jmattson@...gle.com; joro@...tes.org;
> > kvm@...r.kernel.org; linux-kernel@...r.kernel.org; metikaya@...zon.co.uk; mingo@...hat.com;
> > pbonzini@...hat.com; rkrcmar@...hat.com; sean.j.christopherson@...el.com; tglx@...utronix.de;
> > vkuznets@...hat.com; wanpengli@...cent.com; x86@...nel.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?

*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.