From patchwork Thu Jan 5 02:19:52 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Guo Ren X-Patchwork-Id: 39280 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp81497wrt; Wed, 4 Jan 2023 18:31:55 -0800 (PST) X-Google-Smtp-Source: AMrXdXuDTwCMtNfanO04VgSH+xSu8auvtBkv21Ai86PuPPihqiEMHAVrPrlD2qH8bqXBt2fn+JB4 X-Received: by 2002:a05:6a20:d909:b0:b3:5196:94f2 with SMTP id jd9-20020a056a20d90900b000b3519694f2mr38787544pzb.54.1672885915441; Wed, 04 Jan 2023 18:31:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672885915; cv=none; d=google.com; s=arc-20160816; b=t8ME0o97ZoVtBDaUOF8woqjwvp73XGLykLUS07mJjtCOONlCdUTyCTQBSHHkWt0Vfb A7bbEnztxKEVNpEXNCA4yDNo7nrn3qeatRct3h+UfY5YF9/y8ZDgIHKJxv8PJa9tdoVl OVETOUtSjdqD3nirzF+aJFmpypRJzN8CozKoFhXJyHWbMqbxy4T300fBI0a7iU54kmZQ n1Da0HrQZgfeYqzVwag6xluA+/eI/lT7DFUYqdWsbjHtQ48f+D9WODu7W6gMooiR65Eg cMgx91PZVJPSnOPxv86MpzaJ502YnLs949JiLCzuVFBAGCKvZ2s9f1Jz5tt16jMs0kRQ eBmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=0ahzuVsnsxx3XuP/ECreUJt7VV5FbprY+HaoG2bqfTI=; b=gSW3G5WsGVWbZQsQMs61ijMPmDErl+bfQT2ZwlToaMhwzZEAAm1WK3AGfxsJVuq21n +s4vxFI8KlabSlj7Aj24Dp69t4/WPdkPEVrz1DfAShS4/jHYbx+IOfgSEiwg5Fjfyjzp Weh9KPup/VVbl5cZcj4CkKPoE0mOmY/xAZyaQDkRLhhAtE53WrZoos3OLe9KieoWOij/ FO3n6cXMWOUd+LNDsNMOPXmpdqmr6xIEOmnYdYqhvONQ2Jr28vKtpgVnpWN/xo6gs6pg n38vk0rXgMg/zYY3QXXMyAqdLEyOFJhSZyWucACyXybotgl85OYrAB49BH/Xlh8ZzPzc V/2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=lG+Bni8f; 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=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n14-20020a63e04e000000b0049f5dc6cf7csi16810657pgj.801.2023.01.04.18.31.42; Wed, 04 Jan 2023 18:31:55 -0800 (PST) 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=@kernel.org header.s=k20201202 header.b=lG+Bni8f; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229735AbjAECUN (ORCPT + 99 others); Wed, 4 Jan 2023 21:20:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229447AbjAECUM (ORCPT ); Wed, 4 Jan 2023 21:20:12 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 716394434F for ; Wed, 4 Jan 2023 18:20:11 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0866660C66 for ; Thu, 5 Jan 2023 02:20:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF737C433D2; Thu, 5 Jan 2023 02:20:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672885210; bh=/SL1cw00zjWKqQA9YmCfWS3ctN560Kt6tflCeeJfqsU=; h=From:To:Cc:Subject:Date:From; b=lG+Bni8f9lRDVoQd//3F1jqGsXEMdt+C8POcXcexP3/blv39bMQnCKYUod0/Jr08V 6UXLD3rRZV+ECY2Gg7rwWjzBSozdkCnUXnh3eIjUqqoQi2waYIX4lRDYZS57q61qWC yf+HNl+DX4Qu71pysuAtyGKGcmkxNScTjhzHujmI5nzcAxDQ7Unc5kHRIEkFpKseCM LQxeXfx7uKjOQULDFD7cW15GoebXUkVRt6xs852V4UKGM7KysKgYqarRa4cxVKWxCA +cJUbmDUDagqBrQPMrp9Pv/OCYP5yVxl8otU3LL/n01gEp2p56vjAdIIfwVUNi3LZx /FssF5ggLNRWA== From: guoren@kernel.org To: peterz@infradead.org, longman@redhat.com, mingo@redhat.com Cc: linux-kernel@vger.kernel.org, guoren@kernel.org, Guo Ren , Boqun Feng , Will Deacon Subject: [PATCH V2] locking/qspinlock: Optimize pending state waiting for unlock Date: Wed, 4 Jan 2023 21:19:52 -0500 Message-Id: <20230105021952.3090070-1-guoren@kernel.org> X-Mailer: git-send-email 2.36.1 MIME-Version: 1.0 X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754148021676043642?= X-GMAIL-MSGID: =?utf-8?q?1754148021676043642?= From: Guo Ren When we're pending, we only care about lock value. The xchg_tail wouldn't affect the pending state. That means the hardware thread could stay in a sleep state and leaves the rest execution units' resources of pipeline to other hardware threads. This situation is the SMT scenarios in the same core. Not an entering low-power state situation. Of course, the granularity between cores is "cacheline", but the granularity between SMT hw threads of the same core could be "byte" which internal LSU handles. For example, when a hw-thread yields the resources of the core to other hw-threads, this patch could help the hw-thread stay in the sleep state and prevent it from being woken up by other hw-threads xchg_tail. Link: https://lore.kernel.org/lkml/20221224120545.262989-1-guoren@kernel.org/ Signed-off-by: Guo Ren Signed-off-by: Guo Ren Acked-by: Waiman Long Cc: Peter Zijlstra Cc: Boqun Feng Cc: Will Deacon Cc: Ingo Molnar --- Changes in v2: - Add acked tag - Optimize commit log - Add discussion Link tag --- kernel/locking/qspinlock.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c index 2b23378775fe..ebe6b8ec7cb3 100644 --- a/kernel/locking/qspinlock.c +++ b/kernel/locking/qspinlock.c @@ -371,7 +371,7 @@ void __lockfunc queued_spin_lock_slowpath(struct qspinlock *lock, u32 val) /* * We're pending, wait for the owner to go away. * - * 0,1,1 -> 0,1,0 + * 0,1,1 -> *,1,0 * * this wait loop must be a load-acquire such that we match the * store-release that clears the locked bit and create lock @@ -380,7 +380,7 @@ void __lockfunc queued_spin_lock_slowpath(struct qspinlock *lock, u32 val) * barriers. */ if (val & _Q_LOCKED_MASK) - atomic_cond_read_acquire(&lock->val, !(VAL & _Q_LOCKED_MASK)); + smp_cond_load_acquire(&lock->locked, !VAL); /* * take ownership and clear the pending bit.