Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp4127765rwb; Tue, 6 Sep 2022 03:02:33 -0700 (PDT) X-Google-Smtp-Source: AA6agR6uZsdGVixWvBwQcfIBmWwt3cYHOsDYy/6Ipt8tjTDrTmid72kHgkbH6IcOaANx6NrrPUZM X-Received: by 2002:a17:907:720b:b0:731:6e49:dc93 with SMTP id dr11-20020a170907720b00b007316e49dc93mr39619339ejc.421.1662458552801; Tue, 06 Sep 2022 03:02:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662458552; cv=none; d=google.com; s=arc-20160816; b=Av8N0C24gOYeni8Bxonr950A8B4hj8S33fyQ6CGjeEKKG7nhZF3iYHpfxlVf6oWgUF Wv3wTPtayBst+KUW2ooULsxZazED2YQ59CYMR2NIHjdqfMHiPtivhjNwPq/Ym+O6QQei BxiCNlk/x2uvSQEjMl+nk22neLV7TbMsdYLbBgQWRTzh762nfEM4bZ+oxn/PuPj2G7xn wuU3gAjVg6IMBC6EyU9wPc3LEravy5OtBzhH/IsI5UL9CwLLGlLOJrMhmf0puGQSXiCo IWU+lz74Nvu5VT0ZiZZf8nVlNCseQmiqRgjlYGpqEPLuU08qEpeZG7/wDXjRBOS5+CP0 Hamg== 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:message-id:subject:cc:to:from:date:dkim-signature; bh=MNLJZbzs3IffVT2ulJISek0W3WoFgpI3y30RanCbeAo=; b=0Td2NCSkovO845gh1K19ozySbYhs18Z0M6FJmhtmRdXqOUmFXJU0CKsE11UenDQWFp zMN9l8PmIwraB6U92iIfEILlu7yUpSl5COLT1pb1YewSNa/gQeen0ily3JQ9UcluHcOl TCr0ZPAIcUbGZhNLQyT+c/zMThk870MFq22cT0Sjf7/h2Ys2N/au6KEzo6qSJyCXVG/i XEuk6RH3ZpxwIVUZHsWZ1gNpUGG9VSiU3RkBZ/zB8JXARtQ2cdL4b4g+s44B/eNjCJRn IybPGgzHo5AL+pZcR7YvFLxco6fHzQN+vwM9eoJOMhCXuxeqM/dY74IO8VCWdegD3Rzt +ayw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=t4OoI6h7; 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 nd11-20020a170907628b00b0074156b2af5fsi5688128ejc.829.2022.09.06.03.01.42; Tue, 06 Sep 2022 03:02:32 -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=t4OoI6h7; 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 S239613AbiIFJtQ (ORCPT + 99 others); Tue, 6 Sep 2022 05:49:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40382 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239563AbiIFJs5 (ORCPT ); Tue, 6 Sep 2022 05:48:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC43077578; Tue, 6 Sep 2022 02:48:56 -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 8767D61447; Tue, 6 Sep 2022 09:48:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 658F4C433C1; Tue, 6 Sep 2022 09:48:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1662457735; bh=smvlnDa2aUP9CQxZLZ4OAcvHkFcZN1wTPEeebRVS+70=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t4OoI6h7n6xQNy/mkYb2L/acJbi0amTjMTX7xvzvKCGFTF70rSyIX5JWXWrek5UNf ra4KDvsljow2BAdsV9NtQI2qWGyg7HXBaLiYqSy0IYtnZqGay91VjSmhsRN7j3Ptr7 0WBRc3CD78xXLpHlClWlzOA1o6U2L64A6/N5V2RR80eYEXpu8i0cmUnd4ZY2Ud2RWV WYuyABDeVhgBsgOTzduqJwg/sesxDDBscBY3K9li9ek99wC7/CsGE1KbgVwr6bi4jN RGbrp8V1bBBCkFsSwvOEcq8+NC1cTSb5WjFskYol7wD4C/2lAwA8SC8qMityvTjfIz IY159b02FabEA== Date: Tue, 6 Sep 2022 11:48:52 +0200 From: Frederic Weisbecker To: Joel Fernandes Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org, rushikesh.s.kadam@intel.com, urezki@gmail.com, neeraj.iitr10@gmail.com, paulmck@kernel.org, rostedt@goodmis.org, vineeth@bitbyteword.org, boqun.feng@gmail.com Subject: Re: [PATCH v5 04/18] rcu: Fix late wakeup when flush of bypass cblist happens Message-ID: <20220906094852.GA174244@lothringen> References: <20220901221720.1105021-1-joel@joelfernandes.org> <20220901221720.1105021-5-joel@joelfernandes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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,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 Tue, Sep 06, 2022 at 03:07:05AM +0000, Joel Fernandes wrote: > On Thu, Sep 01, 2022 at 10:17:06PM +0000, Joel Fernandes (Google) wrote: > From: "Joel Fernandes (Google)" > Subject: [PATCH v6] rcu: Fix late wakeup when flush of bypass cblist happens > > When the bypass cblist gets too big or its timeout has occurred, it is > flushed into the main cblist. However, the bypass timer is still running > and the behavior is that it would eventually expire and wake the GP > thread. > > Since we are going to use the bypass cblist for lazy CBs, do the wakeup > soon as the flush happens. Otherwise, the lazy-timer will go off much > later and the now-non-lazy cblist CBs can get stranded for the duration > of the timer. > > This is a good thing to do anyway (regardless of this series), since it > makes the behavior consistent with behavior of other code paths where queueing > something into the ->cblist makes the GP kthread in a non-sleeping state > quickly. > > [ Frederic Weisbec: changes to not do wake up GP thread unless needed ]. > > Signed-off-by: Joel Fernandes (Google) > --- > kernel/rcu/tree_nocb.h | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/kernel/rcu/tree_nocb.h b/kernel/rcu/tree_nocb.h > index 0a5f0ef41484..4dc86274b3e8 100644 > --- a/kernel/rcu/tree_nocb.h > +++ b/kernel/rcu/tree_nocb.h > @@ -433,8 +433,9 @@ static bool rcu_nocb_try_bypass(struct rcu_data *rdp, struct rcu_head *rhp, > if ((ncbs && j != READ_ONCE(rdp->nocb_bypass_first)) || > ncbs >= qhimark) { > rcu_nocb_lock(rdp); > + *was_alldone = !rcu_segcblist_pend_cbs(&rdp->cblist); > + > if (!rcu_nocb_flush_bypass(rdp, rhp, j)) { > - *was_alldone = !rcu_segcblist_pend_cbs(&rdp->cblist); > if (*was_alldone) > trace_rcu_nocb_wake(rcu_state.name, rdp->cpu, > TPS("FirstQ")); > @@ -447,7 +448,13 @@ static bool rcu_nocb_try_bypass(struct rcu_data *rdp, struct rcu_head *rhp, > rcu_advance_cbs_nowake(rdp->mynode, rdp); > rdp->nocb_gp_adv_time = j; > } > - rcu_nocb_unlock_irqrestore(rdp, flags); > + > + // The flush succeeded and we moved CBs into the ->cblist. > + // However, the bypass timer might still be running. Wakeup the That part of the comment mentioning the bypass timer looks strange... > + // GP thread by calling a helper with was_all_done set so that > + // wake up happens (needed if main CB list was empty before). How about: // The flush succeeded and we moved CBs into the regular list. // Don't wait for the wake up timer as it may be too far ahead. // Wake up now GP thread instead if the cblist was empty Thanks. Other than that the patch looks good, thanks! > + __call_rcu_nocb_wake(rdp, *was_alldone, flags); > + > return true; // Callback already enqueued. > } > > -- > 2.37.2.789.g6183377224-goog >