From: Geert Uytterhoeven <geert+renesas@glider.be>
To: Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
Magnus Damm <magnus.damm@gmail.com>,
Joerg Roedel <joro@8bytes.org>,
Robin Murphy <robin.murphy@arm.com>
Cc: Tomasz Figa <tomasz.figa@gmail.com>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
Will Deacon <will@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Dejin Zheng <zhengdejin5@gmail.com>,
Kai-Heng Feng <kai.heng.feng@canonical.com>,
Nicholas Piggin <npiggin@gmail.com>,
Heiko Carstens <hca@linux.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Russell King <linux@armlinux.org.uk>,
John Stultz <jstultz@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Tony Lindgren <tony@atomide.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Tero Kristo <tero.kristo@linux.intel.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-pm@vger.kernel.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
Geert Uytterhoeven <geert+renesas@glider.be>
Subject: [PATCH v3 1/7] iopoll: Call cpu_relax() in busy loops
Date: Fri, 2 Jun 2023 10:50:36 +0200 [thread overview]
Message-ID: <45c87bec3397fdd704376807f0eec5cc71be440f.1685692810.git.geert+renesas@glider.be> (raw)
In-Reply-To: <cover.1685692810.git.geert+renesas@glider.be>
It is considered good practice to call cpu_relax() in busy loops, see
Documentation/process/volatile-considered-harmful.rst. This can not
only lower CPU power consumption or yield to a hyperthreaded twin
processor, but also allows an architecture to mitigate hardware issues
(e.g. ARM Erratum 754327 for Cortex-A9 prior to r2p0) in the
architecture-specific cpu_relax() implementation.
In addition, cpu_relax() is also a compiler barrier. It is not
immediately obvious that the @op argument "function" will result in an
actual function call (e.g. in case of inlining).
Where a function call is a C sequence point, this is lost on inlining.
Therefore, with agressive enough optimization it might be possible for
the compiler to hoist the:
(val) = op(args);
"load" out of the loop because it doesn't see the value changing. The
addition of cpu_relax() would inhibit this.
As the iopoll helpers lack calls to cpu_relax(), people are sometimes
reluctant to use them, and may fall back to open-coded polling loops
(including cpu_relax() calls) instead.
Fix this by adding calls to cpu_relax() to the iopoll helpers:
- For the non-atomic case, it is sufficient to call cpu_relax() in
case of a zero sleep-between-reads value, as a call to
usleep_range() is a safe barrier otherwise. However, it doesn't
hurt to add the call regardless, for simplicity, and for similarity
with the atomic case below.
- For the atomic case, cpu_relax() must be called regardless of the
sleep-between-reads value, as there is no guarantee all
architecture-specific implementations of udelay() handle this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
---
v3:
- Add Reviewed-by,
v2:
- Add Acked-by,
- Add compiler barrier and inlining explanation (thanks, Peter!).
---
include/linux/iopoll.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h
index 2c8860e406bd8cae..0417360a6db9b0d6 100644
--- a/include/linux/iopoll.h
+++ b/include/linux/iopoll.h
@@ -53,6 +53,7 @@
} \
if (__sleep_us) \
usleep_range((__sleep_us >> 2) + 1, __sleep_us); \
+ cpu_relax(); \
} \
(cond) ? 0 : -ETIMEDOUT; \
})
@@ -95,6 +96,7 @@
} \
if (__delay_us) \
udelay(__delay_us); \
+ cpu_relax(); \
} \
(cond) ? 0 : -ETIMEDOUT; \
})
--
2.34.1
next prev parent reply other threads:[~2023-06-02 8:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 8:50 [PATCH v3 0/7] iopoll: Busy loop and timeout improvements + conversions Geert Uytterhoeven
2023-06-02 8:50 ` Geert Uytterhoeven [this message]
2023-06-02 8:50 ` [PATCH v3 2/7] iopoll: Do not use timekeeping in read_poll_timeout_atomic() Geert Uytterhoeven
2024-03-26 1:31 ` Zong Li
2024-04-18 9:20 ` Geert Uytterhoeven
2023-06-02 8:50 ` [PATCH v3 3/7] clk: renesas: cpg-mssr: Convert to readl_poll_timeout_atomic() Geert Uytterhoeven
2023-06-02 8:50 ` [PATCH v3 4/7] clk: renesas: mstp: " Geert Uytterhoeven
2023-06-02 8:50 ` [PATCH v3 5/7] clk: renesas: rzg2l: " Geert Uytterhoeven
2023-06-02 8:50 ` [PATCH v3 6/7] soc: renesas: rmobile-sysc: " Geert Uytterhoeven
2023-06-02 13:51 ` kernel test robot
2023-06-05 13:15 ` Geert Uytterhoeven
2023-06-02 8:50 ` [PATCH v3 7/7] iommu/ipmmu-vmsa: Convert to read_poll_timeout_atomic() Geert Uytterhoeven
2023-06-05 15:08 ` [PATCH v3 0/7] iopoll: Busy loop and timeout improvements + conversions Geert Uytterhoeven
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=45c87bec3397fdd704376807f0eec5cc71be440f.1685692810.git.geert+renesas@glider.be \
--to=geert+renesas@glider.be \
--cc=arnd@arndb.de \
--cc=hca@linux.ibm.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=jstultz@google.com \
--cc=kai.heng.feng@canonical.com \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=magnus.damm@gmail.com \
--cc=mturquette@baylibre.com \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=robin.murphy@arm.com \
--cc=s.nawrocki@samsung.com \
--cc=sboyd@kernel.org \
--cc=tero.kristo@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=tomasz.figa@gmail.com \
--cc=tony@atomide.com \
--cc=ulf.hansson@linaro.org \
--cc=vincent.guittot@linaro.org \
--cc=will@kernel.org \
--cc=wsa+renesas@sang-engineering.com \
--cc=yoshihiro.shimoda.uh@renesas.com \
--cc=zhengdejin5@gmail.com \
/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 NNTP newsgroup(s).