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 31618C67861 for ; Mon, 8 Apr 2024 20:05:22 +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:MIME-Version:Content-ID:In-Reply-To: References:Message-ID:Date:CC:To:From:Subject:Reply-To:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=QoO6inyXzG2s5wd5NqGyfds3BEuoT0zrvO/kgP9zPTg=; b=lAnfa8U7rSGqvL dJ31n28Z0DRISTXYNNkF7mxI5FA1mWu1o0saj6YCIp0cXFNCYVXqOXpWCxNl17/GpgaDDqanr50dV JG+7050vLdkXxkKopxiEOGKBFAsXEtNQLTJio11uNoAAXT1XCZQ8Akbk5IcwtFly5e1xmXdIlbbam rr3MuAuAedclgVG6ScT+NKKq14s100aNQUu+ggdunFBQrc3wqPoIoRTTSruBMLzvuvsKzeicUxNML VsmNvYldZwOTxowR924gkLZZkIZq29zulIzrvztBOVreigNfbU6qRir8Lto7eHULBz3SoKlTfznpI nRaeSKNOEFlYFmOZukzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rtvEo-0000000Ghd8-25Gs; Mon, 08 Apr 2024 20:05:06 +0000 Received: from smtp-fw-9102.amazon.com ([207.171.184.29]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rtvEk-0000000GhaO-2Avn for linux-arm-kernel@lists.infradead.org; Mon, 08 Apr 2024 20:05:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1712606703; x=1744142703; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=S9K9SCByMM0ty79uj3ySt7qPf8AIZdDC95KuiV37yiE=; b=hCd1AixAJQvsMUP8cYF9Gm+0X8xv6FxRiXRAc3ioifQc/n3MRzgsV0QF BJdlldKcoPODlm6QYe+9zeCAcXA9owYs+bTkTT5k+IphpVnMSfNEywPNs Zmmcl5HjCOczyjmzJM8tRnoFCVqcw15XHTdTtL3UqTLw/Q/VMTUVbvlE1 w=; X-IronPort-AV: E=Sophos;i="6.07,187,1708387200"; d="scan'208";a="410040860" Subject: Re: [PATCH v4 7/8] cpuidle/poll_state: replace cpu_relax with smp_cond_load_relaxed Thread-Topic: [PATCH v4 7/8] cpuidle/poll_state: replace cpu_relax with smp_cond_load_relaxed Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.25.36.214]) by smtp-border-fw-9102.sea19.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2024 20:04:50 +0000 Received: from EX19MTAUWC002.ant.amazon.com [10.0.21.151:2613] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.59.148:2525] with esmtp (Farcaster) id 5c05a5f2-5bd7-4620-b836-ee947f766195; Mon, 8 Apr 2024 20:04:49 +0000 (UTC) X-Farcaster-Flow-ID: 5c05a5f2-5bd7-4620-b836-ee947f766195 Received: from EX19D001UWA002.ant.amazon.com (10.13.138.236) by EX19MTAUWC002.ant.amazon.com (10.250.64.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 8 Apr 2024 20:04:49 +0000 Received: from EX19D001UWA003.ant.amazon.com (10.13.138.211) by EX19D001UWA002.ant.amazon.com (10.13.138.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.28; Mon, 8 Apr 2024 20:04:49 +0000 Received: from EX19D001UWA003.ant.amazon.com ([fe80::256a:26de:3ee6:48a2]) by EX19D001UWA003.ant.amazon.com ([fe80::256a:26de:3ee6:48a2%7]) with mapi id 15.02.1258.028; Mon, 8 Apr 2024 20:04:49 +0000 From: "Okanovic, Haris" To: "ankur.a.arora@oracle.com" CC: "joao.m.martins@oracle.com" , "kvm@vger.kernel.org" , "dianders@chromium.org" , "rick.p.edgecombe@intel.com" , "rafael@kernel.org" , "pmladek@suse.com" , "wanpengli@tencent.com" , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "catalin.marinas@arm.com" , "mingo@redhat.com" , "pbonzini@redhat.com" , "tglx@linutronix.de" , "daniel.lezcano@linaro.org" , "arnd@arndb.de" , "mihai.carabas@oracle.com" , "will@kernel.org" , "hpa@zytor.com" , "peterz@infradead.org" , "mic@digikod.net" , "vkuznets@redhat.com" , "linux-arm-kernel@lists.infradead.org" , "Okanovic, Haris" , "linux-pm@vger.kernel.org" , "bp@alien8.de" , "juerg.haefliger@canonical.com" , "npiggin@gmail.com" , "x86@kernel.org" Thread-Index: AQHahgAj0rMfU3rQtUK6VuthoD2QJ7FaOuMAgAAXOYCAAUWwAIADJkCAgAAV9oA= Date: Mon, 8 Apr 2024 20:04:49 +0000 Message-ID: References: <1707982910-27680-1-git-send-email-mihai.carabas@oracle.com> <1707982910-27680-8-git-send-email-mihai.carabas@oracle.com> <7f3e540ad30f40ae51f1abda24b1bea2c8b648ea.camel@amazon.com> <87r0fjtn9y.fsf@oracle.com> <87il0rsnf0.fsf@oracle.com> In-Reply-To: <87il0rsnf0.fsf@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.239.17] Content-ID: <7424BB664F26AD4896FB1D47A7C36049@amazon.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240408_130502_651465_FC942360 X-CRM114-Status: GOOD ( 45.48 ) 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 Mon, 2024-04-08 at 11:46 -0700, Ankur Arora wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Okanovic, Haris writes: > > > On Fri, 2024-04-05 at 16:14 -0700, Ankur Arora wrote: > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > > Okanovic, Haris writes: > > > > > > > On Thu, 2024-02-15 at 09:41 +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 | 15 ++++++++++----- > > > > > 1 file changed, 10 insertions(+), 5 deletions(-) > > > > > > > > > > diff --git a/drivers/cpuidle/poll_state.c b/drivers/cpuidle/poll_state.c > > > > > index 9b6d90a72601..1e45be906e72 100644 > > > > > --- a/drivers/cpuidle/poll_state.c > > > > > +++ b/drivers/cpuidle/poll_state.c > > > > > @@ -13,6 +13,7 @@ > > > > > static int __cpuidle poll_idle(struct cpuidle_device *dev, > > > > > struct cpuidle_driver *drv, int index) > > > > > { > > > > > + unsigned long ret; > > > > > u64 time_start; > > > > > > > > > > time_start = local_clock_noinstr(); > > > > > @@ -26,12 +27,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; > > > > > + > > > > > + ret = smp_cond_load_relaxed(¤t_thread_info()->flags, > > > > > + VAL & _TIF_NEED_RESCHED || > > > > > + loop_count++ >= POLL_IDLE_RELAX_COUNT); > > > > > > > > Is it necessary to repeat this 200 times with a wfe poll? > > > > > > The POLL_IDLE_RELAX_COUNT is there because on x86 each cpu_relax() > > > iteration is much shorter. > > > > > > With WFE, it makes less sense. > > > > > > > Does kvm not implement a timeout period? > > > > > > Not yet, but it does become more useful after a WFE haltpoll is > > > available on ARM64. > > > > Note that kvm conditionally traps WFE and WFI based on number of host > > CPU tasks. VMs will sometimes see hardware behavior - potentially > > polling for a long time before entering WFI. > > > > https://elixir.bootlin.com/linux/latest/source/arch/arm64/kvm/arm.c#L459 > > Yeah. There was a discussion on this > https://lore.kernel.org/lkml/871qc6qufy.fsf@oracle.com/. > > > > Haltpoll does have a timeout, which you should be able to tune via > > > /sys/module/haltpoll/parameters/ but that, of course, won't help here. > > > > > > > Could you make it configurable? This patch improves certain workloads > > > > on AWS Graviton instances as well, but blocks up to 6ms in 200 * 30us > > > > increments before going to wfi, which is a bit excessive. > > > > > > Yeah, this looks like a problem. We could solve it by making it an > > > architectural parameter. Though I worry about ARM platforms with > > > much smaller default timeouts. > > > The other possibility is using WFET in the primitive, but then we > > > have that dependency and that's a bigger change. > > > > See arm64's delay() for inspiration: > > > > https://elixir.bootlin.com/linux/v6.9-rc2/source/arch/arm64/lib/delay.c#L26 > > Sure, that part is straight-forward enough. However, this will need a fallback > the case when WFET is not available. And, because this path is used on x86, > so we need a cross platform smp_cond*timeout(). Though given that the x86 > version is based on cpu_relax() then that could just fold the sched_clock() > check in. I was trying to point out how delay() handles different configurations: It prefers WFET when available, falls back to WFE when event stream is available, and finally falls back to cpu_relax() as last resort. Same logic can apply here. The x86 case can always use cpu_relax() fallback, for same behavior as smp_cond_load_relaxed(). Re your concern about "ARM platforms with much smaller default timeouts": You could do something different when arch_timer_get_rate() is too small. Although I'm not sure this is a huge concern, given that delay() doesn't seem to care in the WFE case. -- Haris Okanovic > > Maybe another place to do this would be by KVM forcing a WFE timeout. Arguably > that is needed regardless of whether we use a smp_cond*timeout() or not. > > -- > ankur _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel