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.
