Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp6812669rwl; Wed, 22 Mar 2023 16:28:24 -0700 (PDT) X-Google-Smtp-Source: AK7set8WRQp1poMBHL1S7qAYjAcqFdgrk8LLH5ScMEUiPImQQi/I/JZgkxqSC2FNpPgfsXBwV0j6 X-Received: by 2002:a17:906:cd1:b0:932:3688:ae81 with SMTP id l17-20020a1709060cd100b009323688ae81mr8802780ejh.9.1679527703985; Wed, 22 Mar 2023 16:28:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679527703; cv=none; d=google.com; s=arc-20160816; b=k8VlYANveEdIo3QdwjeL/K2mnOlCh5TPPKRvA8LbsCKibdLg8zxn2b4rTCa/1LMSzF 3mU076e5+Tbc1wGLoVwtFz3iNGlD8CofiaHSo1tT0snCaaV+RGdmz9XuJTOtfxM9ttIe Bo9rX4rPfmnVCeMKaR/tQGpxwPVV2FrycrGBRCAXnosYCGT5QjNMSUkChFJ1LCI8Ep8z xYnHl0Tqww/KQokCxFypcVf5481IQNE3ggKLKgvpWD/A9WjhObX7YpUXjS0rfRwmJGxM RH8K1p20lso+i4+JsdAeK/lkZRFh8njSct+3ugE/ecQGZ/2sQ6JbZ+ALM7AmNzUBuLpq wf2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=OtkTFYGf6ywzxnqLcSwIQPgzG4/Gf/GcxMQYVWd85g8=; b=x0MkNXgRTmhJVEtbocQkP1cfH0Vy4WMuwC1ACZZQ7yckg/JEF0e5iQcJXatCCuoy/y fkow9OCDKwx1RKpF2FLvOfkVvwYretKLBffaxFNjzZRmOMnMcBYstruP/zeB6wRkBBod HJiZO56Yl4B2xAJZ6c2eMlBbmWzhxmTTWybnmU+a31az43HP6oKiypf10nPd1qvt1vjO VbrI5stVU1Cwsy+TDGqZsSsqOJNc5dz2omGGSqgsS2+0pYyu05CReXFspjkB26HKsnG2 OU87kubc86J84O9dVwN1zbSprMDCEXQD5chMPAGN63yh0xElpD75VNcG01apq74IUWG7 ylbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=V9ALjO2H; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t21-20020a1709063e5500b0092bdf20dfefsi15035615eji.386.2023.03.22.16.27.59; Wed, 22 Mar 2023 16:28:23 -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=@kernel.org header.s=k20201202 header.b=V9ALjO2H; 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 S229801AbjCVXV5 (ORCPT + 99 others); Wed, 22 Mar 2023 19:21:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229745AbjCVXVz (ORCPT ); Wed, 22 Mar 2023 19:21:55 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CE7220D23; Wed, 22 Mar 2023 16:21:50 -0700 (PDT) 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 CC9D362306; Wed, 22 Mar 2023 23:21:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3EEADC433D2; Wed, 22 Mar 2023 23:21:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679527309; bh=0RxS9LzwqEuTpc0Cc7hCnYLzybmb7bUKnNrtE5zK+bs=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=V9ALjO2HecoXi/TgMkx805aggmhFZnwvg0FS4sGwJZaQ1doK7ga/PEjuaK9sFRfdB YlHfGIpACSeI1Agaa5LQoAAHMKykzVcTR9un3sD4vmxnSi22ef/9rivCgBkBgaJxh3 CIHK3QScB5U3jfEosKnnomKMWniaQeMSbvx/U3nyDVCvvRTxmfjT/LFwCG4P0vf+ZL h3KCAVmgy7uSt7e53RqVreznOE//gLT53GGDMr+9bGzyX4bmBqAG1ynG2iALlrBl4r YCBaHI6mjaEhfhi9ermaUzIsJUMNEMxRFEGSHjaGp5DW0whXv47vtfL76tzO//4xf4 GxDmuZCu7MkaQ== Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id CB3EA1540397; Wed, 22 Mar 2023 16:21:48 -0700 (PDT) Date: Wed, 22 Mar 2023 16:21:48 -0700 From: "Paul E. McKenney" To: Frederic Weisbecker Cc: LKML , rcu , Uladzislau Rezki , Neeraj Upadhyay , Boqun Feng , Joel Fernandes Subject: Re: [PATCH 3/4] rcu/nocb: Recheck lazy callbacks under the ->nocb_lock from shrinker Message-ID: <29087017-d349-4710-a7cb-04948fb104df@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20230322194456.2331527-1-frederic@kernel.org> <20230322194456.2331527-4-frederic@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230322194456.2331527-4-frederic@kernel.org> X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=unavailable 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, Mar 22, 2023 at 08:44:55PM +0100, Frederic Weisbecker wrote: > The ->lazy_len is only checked locklessly. Recheck again under the > ->nocb_lock to avoid spending more time on flushing/waking if not > necessary. The ->lazy_len can still increment concurrently (from 1 to > infinity) but under the ->nocb_lock we at least know for sure if there > are lazy callbacks at all (->lazy_len > 0). > > Signed-off-by: Frederic Weisbecker This one looks plausible, and might hold the answer to earlier questions. Thanx, Paul > --- > kernel/rcu/tree_nocb.h | 16 ++++++++++++---- > 1 file changed, 12 insertions(+), 4 deletions(-) > > diff --git a/kernel/rcu/tree_nocb.h b/kernel/rcu/tree_nocb.h > index cb57e8312231..a3dc7465b0b2 100644 > --- a/kernel/rcu/tree_nocb.h > +++ b/kernel/rcu/tree_nocb.h > @@ -1350,12 +1350,20 @@ lazy_rcu_shrink_scan(struct shrinker *shrink, struct shrink_control *sc) > if (!rcu_rdp_is_offloaded(rdp)) > continue; > > + if (!READ_ONCE(rdp->lazy_len)) > + continue; > + > + rcu_nocb_lock_irqsave(rdp, flags); > + /* > + * Recheck under the nocb lock. Since we are not holding the bypass > + * lock we may still race with increments from the enqueuer but still > + * we know for sure if there is at least one lazy callback. > + */ > _count = READ_ONCE(rdp->lazy_len); > - > - if (_count == 0) > + if (!_count) { > + rcu_nocb_unlock_irqrestore(rdp, flags); > continue; > - > - rcu_nocb_lock_irqsave(rdp, flags); > + } > WARN_ON_ONCE(!rcu_nocb_flush_bypass(rdp, NULL, jiffies, false)); > rcu_nocb_unlock_irqrestore(rdp, flags); > wake_nocb_gp(rdp, false); > -- > 2.34.1 >