linux-kernel - Re: [PATCH 1/9] cpuidle: rename ARCH_HAS_CPU_RELAX to ARCH_HAS_OPTIMIZED

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Wed, 1 May 2024 18:33:42 -0700 (PDT)
From: "Christoph Lameter (Ampere)" <cl@...two.org>
To: Ankur Arora <ankur.a.arora@...cle.com>
cc: linux-pm@...r.kernel.org, kvm@...r.kernel.org, 
    linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
    catalin.marinas@....com, will@...nel.org, tglx@...utronix.de, 
    mingo@...hat.com, bp@...en8.de, x86@...nel.org, hpa@...or.com, 
    pbonzini@...hat.com, wanpengli@...cent.com, vkuznets@...hat.com, 
    rafael@...nel.org, daniel.lezcano@...aro.org, peterz@...radead.org, 
    arnd@...db.de, lenb@...nel.org, mark.rutland@....com, harisokn@...zon.com, 
    joao.m.martins@...cle.com, boris.ostrovsky@...cle.com, 
    konrad.wilk@...cle.com
Subject: Re: [PATCH 1/9] cpuidle: rename ARCH_HAS_CPU_RELAX to
 ARCH_HAS_OPTIMIZED_POLL

On Tue, 30 Apr 2024, Ankur Arora wrote:

> ARCH_HAS_CPU_RELAX is a bit of a misnomer since all architectures
> define cpu_relax(). Not all, however, have a performant version, with
> some only implementing it as a compiler barrier.
>
> In contexts that this config option is used, it is expected to provide
> an architectural primitive that can be used as part of a polling
> mechanism -- one that would be cheaper than spinning in a tight loop.

The intend of cpu_relax() is not a polling mechanism. Initial AFAICT it 
was introduced on x86 as the REP NOP instruction. Aka as PAUSE. And it was 
part of a spin loop. So there was no connection to polling anything.

The intend was to make the processor aware that we are in a spin loop. 
Various processors have different actions that they take upon encountering 
such a cpu relax operation.

The polling (WFE/WFI) available on ARM (and potentially other platforms) 
is a different mechanism that is actually intended to reduce the power 
requirement of the processor until a certain condition is met and that 
check is done in hardware.

These are not the same and I think we need both config options.

The issues that you have with WFET later in the patchset arise from not 
making this distinction.

The polling (waiting for an event) could be implemented for a 
processor not supporting that in hardware by using a loop that 
checks for the condition and then does a cpu_relax().

With that you could f.e. support the existing cpu_relax() and also have 
some form of cpu_poll() interface.