From: "Christoph Lameter (Ampere)" <cl@gentwo.org>
To: Ankur Arora <ankur.a.arora@oracle.com>
Cc: linux-pm@vger.kernel.org, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
will@kernel.org, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, x86@kernel.org, hpa@zytor.com,
pbonzini@redhat.com, wanpengli@tencent.com, vkuznets@redhat.com,
rafael@kernel.org, daniel.lezcano@linaro.org,
peterz@infradead.org, arnd@arndb.de, lenb@kernel.org,
mark.rutland@arm.com, harisokn@amazon.com,
joao.m.martins@oracle.com, boris.ostrovsky@oracle.com,
konrad.wilk@oracle.com
Subject: Re: [PATCH 1/9] cpuidle: rename ARCH_HAS_CPU_RELAX to ARCH_HAS_OPTIMIZED_POLL
Date: Wed, 1 May 2024 18:33:42 -0700 (PDT) [thread overview]
Message-ID: <7473bd3d-f812-e039-24cf-501502206dc9@gentwo.org> (raw)
In-Reply-To: <20240430183730.561960-2-ankur.a.arora@oracle.com>
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.
next prev parent reply other threads:[~2024-05-02 1:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 18:37 [PATCH 0/9] Enable haltpoll for arm64 Ankur Arora
2024-04-30 18:37 ` [PATCH 1/9] cpuidle: rename ARCH_HAS_CPU_RELAX to ARCH_HAS_OPTIMIZED_POLL Ankur Arora
2024-05-02 1:33 ` Christoph Lameter (Ampere) [this message]
2024-05-03 4:13 ` Ankur Arora
2024-05-03 17:07 ` Christoph Lameter (Ampere)
2024-05-06 21:27 ` Ankur Arora
2024-04-30 18:37 ` [PATCH 2/9] Kconfig: move ARCH_HAS_OPTIMIZED_POLL to arch/Kconfig Ankur Arora
2024-04-30 18:37 ` [PATCH 3/9] cpuidle-haltpoll: condition on ARCH_CPUIDLE_HALTPOLL Ankur Arora
2024-05-22 16:09 ` Joao Martins
2024-04-30 18:37 ` [PATCH 4/9] cpuidle-haltpoll: define arch_haltpoll_supported() Ankur Arora
2024-05-01 11:48 ` kernel test robot
2024-05-22 16:09 ` Joao Martins
2024-06-05 5:47 ` Ankur Arora
2024-04-30 18:37 ` [PATCH 5/9] governors/haltpoll: drop kvm_para_available() check Ankur Arora
2024-04-30 18:37 ` [PATCH 6/9] cpuidle/poll_state: poll via smp_cond_load_relaxed() Ankur Arora
2024-04-30 18:37 ` [PATCH 7/9] arm64: define TIF_POLLING_NRFLAG Ankur Arora
2024-04-30 18:37 ` [PATCH 8/9] arm64: support cpuidle-haltpoll Ankur Arora
2024-05-30 23:07 ` Okanovic, Haris
2024-06-04 23:09 ` Ankur Arora
2024-04-30 18:37 ` [PATCH 9/9] cpuidle/poll_state: limit POLL_IDLE_RELAX_COUNT on arm64 Ankur Arora
2024-04-30 18:56 ` [PATCH 0/9] Enable haltpoll for arm64 Ankur Arora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7473bd3d-f812-e039-24cf-501502206dc9@gentwo.org \
--to=cl@gentwo.org \
--cc=ankur.a.arora@oracle.com \
--cc=arnd@arndb.de \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=harisokn@amazon.com \
--cc=hpa@zytor.com \
--cc=joao.m.martins@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=lenb@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).