[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <38a9a8f8-6bc7-42aa-b5e2-0148371e29c8@app.fastmail.com>
Date: Thu, 26 Jan 2023 13:07:29 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Geert Uytterhoeven" <geert+renesas@...der.be>,
"Stephen Boyd" <sboyd@...nel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski@...aro.org>,
"Tomasz Figa" <tomasz.figa@...il.com>,
"Sylwester Nawrocki" <s.nawrocki@...sung.com>,
"Will Deacon" <will@...nel.org>,
"Wolfram Sang" <wsa+renesas@...g-engineering.com>,
"Dejin Zheng" <zhengdejin5@...il.com>,
"Kai-Heng Feng" <kai.heng.feng@...onical.com>,
"Nicholas Piggin" <npiggin@...il.com>,
"Heiko Carstens" <hca@...ux.ibm.com>,
"Peter Zijlstra" <peterz@...radead.org>,
"Russell King" <linux@...linux.org.uk>
Cc: linux-arm-kernel@...ts.infradead.org,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
Linux-Arch <linux-arch@...r.kernel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH resend] iopoll: Call cpu_relax() in busy loops
On Thu, Jan 26, 2023, at 11:45, Geert Uytterhoeven wrote:
> 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.
>
> 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.
> - 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@...der.be>
Acked-by: Arnd Bergmann <arnd@...db.de>
Powered by blists - more mailing lists