Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp8545829rwr; Thu, 11 May 2023 02:52:55 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7DAlf5AqDBJookLp6hML0gR7ZezCNqPe5gxbAE9QYE2CScZRbdy9r97HnBCriN71oa2LMx X-Received: by 2002:a17:902:dad2:b0:1ac:859a:5b5a with SMTP id q18-20020a170902dad200b001ac859a5b5amr15371560plx.0.1683798774788; Thu, 11 May 2023 02:52:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683798774; cv=none; d=google.com; s=arc-20160816; b=IRBm79KY/Eh4a6AdfaU1CtwWe7c+VUoBaEeZoE8NdC1IJoM3T/OA9N5lWz79zFHamF 9egx/m737xFtJO7X23ioInKrT/sTSQPPmnsgZr3CeCUWhl1Lguz4EJ1+PxHkC5dLhcEi 0QZhkBvmkuO3SuKGAV5YaG1OVvwBR3xy2SCrlo9OaBME1S7CqVYYvK/L4Yxuys7qD9g0 X2QeEuOoEkcNjZVIf337oiZfl7azUgrQcLEC0Uqm+pb4O6xTD0WK1qoAVImlSIsKQqRe b3GTMLspg//aLgia0+aMLfBqhRgsT084/XK1M/9ER29wm4CbVV2/hOcHJoK7KBEFoYKD c/wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=vx18VK8gbasjrWf/cSU+rJppsMri3t7m3OEVcEQZqnI=; b=z9vytP7vRBf3Rlex/i/+bO27KsxU+bNEXGTL9tzI37ACZduMufkvH+MXOk/tejqrBV 10m9RRPmoEsPPMR3As89mYhTzhb8AUfv9d7q0KTO/aU254FwZvsMNtEj/signd5ZJ/XP 3j7V5IOmouv7SmGUeC6M91LAhva4rzcVy3tOf+tvht1oQXlht6iV5sVuFdHrn3zsD9Sv qCqIFLjAkJq0+IKbDNEH6gmx2tXHS8wAK54KY9h+VmK9lRgglMj2EO5z9k5GYhKb0FCG CJmm35uTh9Yzzztxmlo+UU5HiodMAJYx+F7uRQMYs7WXk203ZTnNV9Wodk7BvIgjXmmW pg+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=y0vL277m; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z8-20020a170903018800b001a51bb4ad81si6567859plg.44.2023.05.11.02.52.39; Thu, 11 May 2023 02:52:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=y0vL277m; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237639AbjEKJsv (ORCPT + 99 others); Thu, 11 May 2023 05:48:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230292AbjEKJst (ORCPT ); Thu, 11 May 2023 05:48:49 -0400 Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50B7D1FFE for ; Thu, 11 May 2023 02:48:48 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-b9d8b2e1576so10691568276.2 for ; Thu, 11 May 2023 02:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1683798527; x=1686390527; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vx18VK8gbasjrWf/cSU+rJppsMri3t7m3OEVcEQZqnI=; b=y0vL277mhdkg0IVyKVF9Xj5BrJGL4T4KRCytU0vWSXUL5Nn/ZM6nF9bPbE+GHaEanR OGyLRpkxZ2ZfGnIxVlL77bgBiljl86Gtt6NOj2l6MIA1yxcI4yLkOJ6diCpZ8GI5e2wI twdCy5OEhLwuCtSv+5ktrCeaiC13IB5JFArPrF6YbimlRI7PvfV4UIiGlT9YTxQ0hPWG PaHwdRQYt7VM5HYCHMzGcT1URzrGtyfXDAmTLlgAqncsbaHtUBU5yMJmdk2zfMon4/eg JDsb6oRzQrZUYyWjJPmfmKHYYcEJXXhsX47A6PIJkoPGjX5aT01vVdf11bChcrs+BrtI WB5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683798527; x=1686390527; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vx18VK8gbasjrWf/cSU+rJppsMri3t7m3OEVcEQZqnI=; b=FMPJ9EOV29XS4LsbplBhNfhurp5y3HMtz/LM/OxEml/sh0AGLuIQEQEDAuj1DDG2fc puHXJg8IeMo71VKiaKhKm3CdY2Z5Pw+HZgDcE5hBnwdcRUeBe4DryjQYKGqceUCTE4jN eZP6oh1teHp026h5kMMegI/bWb0odwbnq/dKpOyvkDRQUyeXToODeW09ciNLEa62hKVB fNMncxJ67lS4SxUCXwRSnMzYedPSrRCHT4HM7ZI5iyOK9/OBgflI75JtPrEFUAGGOJ0D qJCOHO1G9e9ytzPPiOVLeQvYx31zloBNck3F/LiIczn8Me1xISlKtDnCMFsz511lMRgV O5Gw== X-Gm-Message-State: AC+VfDx6EUca4PHfG+cqr9G+MAcJmSJfKkEq9OoYHM1fubsxqaZxN7LL g3h1ABXp4Q/hz+zYY/gBKXGSQOmngD3axBsQp5TAxw== X-Received: by 2002:a25:d710:0:b0:ba6:bb9a:3e30 with SMTP id o16-20020a25d710000000b00ba6bb9a3e30mr696571ybg.6.1683798527480; Thu, 11 May 2023 02:48:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulf Hansson Date: Thu, 11 May 2023 11:48:11 +0200 Message-ID: Subject: Re: [PATCH v2 1/2] iopoll: Call cpu_relax() in busy loops To: Geert Uytterhoeven Cc: Stephen Boyd , Tomasz Figa , Sylwester Nawrocki , Will Deacon , Arnd Bergmann , Wolfram Sang , Dejin Zheng , Kai-Heng Feng , Nicholas Piggin , Heiko Carstens , Peter Zijlstra , Russell King , John Stultz , Thomas Gleixner , Tony Lindgren , Krzysztof Kozlowski , Tero Kristo , "Rafael J . Wysocki" , Vincent Guittot , linux-arm-kernel@lists.infradead.org, linux-renesas-soc@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 10 May 2023 at 15:23, 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. > > 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 > Acked-by: Peter Zijlstra (Intel) > Acked-by: Arnd Bergmann Makes sense to me! Feel free to add: Reviewed-by: Ulf Hansson Kind regards Uffe > --- > 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 >