Re: [PATCH 1/9] cpuidle: rename ARCH_HAS_CPU_RELAX to ARCH_HAS_OPTIMIZED_POLL

From: Christoph Lameter (Ampere)
Date: Wed May 01 2024 - 21:45:10 EST


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.