From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C52BF3F9FC; Mon, 29 Jan 2024 18:15:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706552156; cv=none; b=C8Y/dBnbLQZWJjvqbdCMo7tnIX1Y2YxRngXsNE+16Vr5UXFgjiZwdwc/p5zrnt8ZQFDFutJr6s5j5dqyPuqF2UF/BuUXhtakXVtOvVg3cHveU1yU9PC1SnL4aLpUDnGlVFPJis/5hvYxrSM84y91F9BoqCtMQ/JabHqijGZ8ys4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706552156; c=relaxed/simple; bh=HtWWFC71BCavDoQvTNSF5iID0oN+lBFa3TU2UQoctyw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=E8AFEhOnkF67a/wpCQHKKde5gWxqYTx+xDqcdg9xAG/T56xjCRxaYDeUOs0Ovm973YFQNBZ5CVYw6bkVK8G4IbgwWvpyxaeTa2Amt+wver0u4Rs0me3J34Bq61A4FEOt7CNAk0jUI0PUjbo6xHW6XB4jLoajOk2hAplh90odN+4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pPW3f9Sj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pPW3f9Sj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A849C433C7; Mon, 29 Jan 2024 18:15:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706552156; bh=HtWWFC71BCavDoQvTNSF5iID0oN+lBFa3TU2UQoctyw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pPW3f9SjldNx036oVfr2mb7rF/1uWtZ+8laYPTJFddNQu22KfZ9+JSUv3x0Zuw9Bs Zg59bttwt3Mq13HLeF7PE+CdppqGpDgui6gYfX2F0YP/bMAsrPRvM5xTKFMs/xgxq0 AKs03jubjF5XETb+5vpA4ubGccF/LgcfoHaiv9vPYmZcxEq+QxwuBLK+1qOOKyz2hB bDObKuNdlKVq94bl6KJx3hVJOl9w6th4nhM+Xg7uZ9cxQowb+FA6/48N6cVWwyJpPH Cya7zQern418k52+XIWRSXC9HRRO//yRjqbXG8Ogd0pMHsMRLRIJNPE8O4O6X4juuj UDdExsudUOJfg== Date: Mon, 29 Jan 2024 18:15:47 +0000 From: Will Deacon To: Mihai Carabas Cc: linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, 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, akpm@linux-foundation.org, pmladek@suse.com, peterz@infradead.org, dianders@chromium.org, npiggin@gmail.com, rick.p.edgecombe@intel.com, joao.m.martins@oracle.com, juerg.haefliger@canonical.com, mic@digikod.net, arnd@arndb.de, ankur.a.arora@oracle.com Subject: Re: [PATCH 7/7] cpuidle/poll_state: replace cpu_relax with smp_cond_load_relaxed Message-ID: <20240129181547.GA12305@willie-the-truck> References: <1700488898-12431-1-git-send-email-mihai.carabas@oracle.com> <1700488898-12431-8-git-send-email-mihai.carabas@oracle.com> <20231211114642.GB24899@willie-the-truck> <1b3650c5-822e-4789-81d2-0304573cabd9@oracle.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b3650c5-822e-4789-81d2-0304573cabd9@oracle.com> User-Agent: Mutt/1.10.1 (2018-07-13) On Sun, Jan 28, 2024 at 11:22:50PM +0200, Mihai Carabas wrote: > La 11.12.2023 13:46, Will Deacon a scris: > > On Mon, Nov 20, 2023 at 04:01:38PM +0200, Mihai Carabas wrote: > > > cpu_relax on ARM64 does a simple "yield". Thus we replace it with > > > smp_cond_load_relaxed which basically does a "wfe". > > > > > > Suggested-by: Peter Zijlstra > > > Signed-off-by: Mihai Carabas > > > --- > > > drivers/cpuidle/poll_state.c | 14 +++++++++----- > > > 1 file changed, 9 insertions(+), 5 deletions(-) > > > > > > diff --git a/drivers/cpuidle/poll_state.c b/drivers/cpuidle/poll_state.c > > > index 9b6d90a72601..440cd713e39a 100644 > > > --- a/drivers/cpuidle/poll_state.c > > > +++ b/drivers/cpuidle/poll_state.c > > > @@ -26,12 +26,16 @@ static int __cpuidle poll_idle(struct cpuidle_device *dev, > > > limit = cpuidle_poll_time(drv, dev); > > > - while (!need_resched()) { > > > - cpu_relax(); > > > - if (loop_count++ < POLL_IDLE_RELAX_COUNT) > > > - continue; > > > - > > > + for (;;) { > > > loop_count = 0; > > > + > > > + smp_cond_load_relaxed(¤t_thread_info()->flags, > > > + (VAL & _TIF_NEED_RESCHED) || > > > + (loop_count++ >= POLL_IDLE_RELAX_COUNT)); > > > + > > > + if (loop_count < POLL_IDLE_RELAX_COUNT) > > > + break; > > > + > > > if (local_clock_noinstr() - time_start > limit) { > > > dev->poll_time_limit = true; > > > break; > > Doesn't this make ARCH_HAS_CPU_RELAX a complete misnomer? > > This controls the build of poll_state.c and the generic definition of > smp_cond_load_relaxed (used by x86) is using cpu_relax(). Do you propose > other approach here? Give it a better name? Having ARCH_HAS_CPU_RELAX control a piece of code that doesn't use cpu_relax() doesn't make sense to me. Will From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D4AF2C47DDB for ; Mon, 29 Jan 2024 18:16:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hwzGj3KVfC/yg5+duglbRLL6pQHlkQtn1uVaF7aaqH0=; b=C8ivYilgT3k04G cs6Lzd0dx0XBHNM+t14Ry5gkidMgtNAE/YtefUJhby2UI/A1+NxtT2RYd8UAaTDYTT24NNGud1M0K /A0qGwkRkxkd/f53VG8TRAMOseN4PpUgwFM+6UL3+63Tx0T+cLnCzAqnSb3sSdXtycUvM8BkxTb0r X3A0AChqGelRZQMrR0jHY6ihqIliGGJJuDF8R/wTR1gCDC1VdBetXcdnv0uaPILpszTZcLemz+0Fy QWyVASkK+A+6pW31RG0QM1b/D9UO9LFEqzP2h1PraFndpnqLSD4yyBN6Zx9IFvLmbn3T9si2DyKfH EmV343U2oLbStW2zec1g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rUWAs-0000000DtfS-3w7i; Mon, 29 Jan 2024 18:16:02 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rUWAq-0000000DteN-25TS for linux-arm-kernel@lists.infradead.org; Mon, 29 Jan 2024 18:16:01 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id E340BCE1694; Mon, 29 Jan 2024 18:15:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A849C433C7; Mon, 29 Jan 2024 18:15:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706552156; bh=HtWWFC71BCavDoQvTNSF5iID0oN+lBFa3TU2UQoctyw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pPW3f9SjldNx036oVfr2mb7rF/1uWtZ+8laYPTJFddNQu22KfZ9+JSUv3x0Zuw9Bs Zg59bttwt3Mq13HLeF7PE+CdppqGpDgui6gYfX2F0YP/bMAsrPRvM5xTKFMs/xgxq0 AKs03jubjF5XETb+5vpA4ubGccF/LgcfoHaiv9vPYmZcxEq+QxwuBLK+1qOOKyz2hB bDObKuNdlKVq94bl6KJx3hVJOl9w6th4nhM+Xg7uZ9cxQowb+FA6/48N6cVWwyJpPH Cya7zQern418k52+XIWRSXC9HRRO//yRjqbXG8Ogd0pMHsMRLRIJNPE8O4O6X4juuj UDdExsudUOJfg== Date: Mon, 29 Jan 2024 18:15:47 +0000 From: Will Deacon To: Mihai Carabas Cc: linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, 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, akpm@linux-foundation.org, pmladek@suse.com, peterz@infradead.org, dianders@chromium.org, npiggin@gmail.com, rick.p.edgecombe@intel.com, joao.m.martins@oracle.com, juerg.haefliger@canonical.com, mic@digikod.net, arnd@arndb.de, ankur.a.arora@oracle.com Subject: Re: [PATCH 7/7] cpuidle/poll_state: replace cpu_relax with smp_cond_load_relaxed Message-ID: <20240129181547.GA12305@willie-the-truck> References: <1700488898-12431-1-git-send-email-mihai.carabas@oracle.com> <1700488898-12431-8-git-send-email-mihai.carabas@oracle.com> <20231211114642.GB24899@willie-the-truck> <1b3650c5-822e-4789-81d2-0304573cabd9@oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1b3650c5-822e-4789-81d2-0304573cabd9@oracle.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240129_101600_735387_467C0A33 X-CRM114-Status: GOOD ( 20.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, Jan 28, 2024 at 11:22:50PM +0200, Mihai Carabas wrote: > La 11.12.2023 13:46, Will Deacon a scris: > > On Mon, Nov 20, 2023 at 04:01:38PM +0200, Mihai Carabas wrote: > > > cpu_relax on ARM64 does a simple "yield". Thus we replace it with > > > smp_cond_load_relaxed which basically does a "wfe". > > > > > > Suggested-by: Peter Zijlstra > > > Signed-off-by: Mihai Carabas > > > --- > > > drivers/cpuidle/poll_state.c | 14 +++++++++----- > > > 1 file changed, 9 insertions(+), 5 deletions(-) > > > > > > diff --git a/drivers/cpuidle/poll_state.c b/drivers/cpuidle/poll_state.c > > > index 9b6d90a72601..440cd713e39a 100644 > > > --- a/drivers/cpuidle/poll_state.c > > > +++ b/drivers/cpuidle/poll_state.c > > > @@ -26,12 +26,16 @@ static int __cpuidle poll_idle(struct cpuidle_device *dev, > > > limit = cpuidle_poll_time(drv, dev); > > > - while (!need_resched()) { > > > - cpu_relax(); > > > - if (loop_count++ < POLL_IDLE_RELAX_COUNT) > > > - continue; > > > - > > > + for (;;) { > > > loop_count = 0; > > > + > > > + smp_cond_load_relaxed(¤t_thread_info()->flags, > > > + (VAL & _TIF_NEED_RESCHED) || > > > + (loop_count++ >= POLL_IDLE_RELAX_COUNT)); > > > + > > > + if (loop_count < POLL_IDLE_RELAX_COUNT) > > > + break; > > > + > > > if (local_clock_noinstr() - time_start > limit) { > > > dev->poll_time_limit = true; > > > break; > > Doesn't this make ARCH_HAS_CPU_RELAX a complete misnomer? > > This controls the build of poll_state.c and the generic definition of > smp_cond_load_relaxed (used by x86) is using cpu_relax(). Do you propose > other approach here? Give it a better name? Having ARCH_HAS_CPU_RELAX control a piece of code that doesn't use cpu_relax() doesn't make sense to me. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel