Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp923465imm; Mon, 21 May 2018 17:20:51 -0700 (PDT) X-Google-Smtp-Source: AB8JxZosn0OxKikcrLA66tL4NSMml8bADXFSgrik0y4EbC826kMEO1lbFdVj5ZFwQJT/OM6hHTmE X-Received: by 2002:a63:7247:: with SMTP id c7-v6mr6269843pgn.68.1526948451344; Mon, 21 May 2018 17:20:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526948451; cv=none; d=google.com; s=arc-20160816; b=BHnCl6J/um25bB6+KFVUfZfjna5GGx/ntsA7Ox2QuZkeV1ma/IhrxQI1Pa7KZXE/GR JOiob1VcUg9Sh8qUqLMOTlaffpBWcKhgAbd2fNtSUYLSqzIgeZIGOuQ+x4FLyvKiMdYr SWbvpGNaMk8tXg7uRNYCuglLCtTbFiB0rdbewiDn91VtED5j3cCPpICApnuoVBbfFmip GpPrHwfIzmogeKu7IynwFl5/1ahu6KPfyLzTY+ijJJs7WdR/z/yMl0HexLAnZ6Oet2LJ iWkFUFHc2CqXsOlBrYVNMbRHBPkwubnxAELMs5n0HICgI9dVpxeIAbEtcHLBFRrid0E6 1o7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=I7pOzMj6spjeRaQyEzJROLqObqTpnqNjdpUpvUIVNJU=; b=LFfRVBjYomPWI3/VwgRsYE17wAOJ0CoZjDRyEsIruB0GD6GWuvWnhAaYJOE3DDJgWO StVgB2WBlrEEaOB8yQL9lnMPNsHlWXDy0jyfDeEnOhFXThIL/eTOl8mIcWXtadwguIVW oVyKJZmsxBgEj91CQMaYgxR3mIEcMDg8YeaO8qPGizSwAJ+dLL1PhfrpuiD5+odg9TqP H6E7jwuWaYJYCbkZr6qcnpnXQ1ey5n73I/BS1ZE+D1YybU7WV3/K3FbXHDfQgEIu5227 jC0H+WeldbQ1pKfSohJ2HN+f+iVzIy+pELMxVFBDBEiPYE5HEnt4knVq8UKroktQffGT pqIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=bl4HlVbz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t193-v6si12000807pgc.572.2018.05.21.17.20.36; Mon, 21 May 2018 17:20:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=bl4HlVbz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751639AbeEVAT4 (ORCPT + 99 others); Mon, 21 May 2018 20:19:56 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:40627 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750859AbeEVATx (ORCPT ); Mon, 21 May 2018 20:19:53 -0400 Received: by mail-pg0-f65.google.com with SMTP id l2-v6so7044681pgc.7 for ; Mon, 21 May 2018 17:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=I7pOzMj6spjeRaQyEzJROLqObqTpnqNjdpUpvUIVNJU=; b=bl4HlVbzlOqDgjEXrj4cuM+T6x1aRqp3J/v0ZJCIXJRd6oGMwR5uKtf5JeavaKj/+6 ED3a7MlWb41e9kQCeSATTLcVAJIQZhpCJ4QbhukVdPhAD7DsVDTzOeyo3LpFMrw22GuP 56cb/Vo/wxtWs1dtvP6ZrdZGJgo6Y7YnWOvm8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=I7pOzMj6spjeRaQyEzJROLqObqTpnqNjdpUpvUIVNJU=; b=o70n2kSZHJLDeVDTR3u3JwzSWQ/MkhIyK3ZDSu+YNQgIYKL+wPgkkU0aDB06/DxOi+ hbf6dcEvMnLEHHMr6knyEtsqP9GOB6ajeXNBsLgkIP2CXAKuvkTkuTpt9EI4KUNuZ2ZF ETDoyi5WdapEtRGZabsVoKalOq+JP7iTDpGiYJhSo4WT6YdzQujW3qwx5894jJ4A6L5a Hd5Y/8qRF1sBM7skgQgnOSHOOK6124z65CnI2USy7AP5HZGJhqqEREwGW8UD6/YGOkwl YGuqgg7HH1wvBTmeh/cZ5vpyKdbYAhc4Jl4jyHbczZKjg+fE7G9CTIiknY9BnN0Uqnml QBZg== X-Gm-Message-State: ALKqPwfvn41oVg7ZzejkbVfotjghPgdwQqmc0ueqPQWsmz6tcb0qx0Ih UbTeAF2lhjHfsdDBkxgsUQxjQQ== X-Received: by 2002:a62:e408:: with SMTP id r8-v6mr22059029pfh.172.1526948393123; Mon, 21 May 2018 17:19:53 -0700 (PDT) Received: from localhost ([2620:0:1000:1600:3122:ea9c:d178:eb]) by smtp.gmail.com with ESMTPSA id i69-v6sm31261960pfk.84.2018.05.21.17.19.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 21 May 2018 17:19:52 -0700 (PDT) Date: Mon, 21 May 2018 17:19:51 -0700 From: Joel Fernandes To: "Paul E. McKenney" Cc: Joel Fernandes , linux-kernel@vger.kernel.org, Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , byungchul.park@lge.com, kernel-team@android.com Subject: Re: [PATCH v3 3/4] rcu: Use better variable names in funnel locking loop Message-ID: <20180522001951.GE40541@joelaf.mtv.corp.google.com> References: <20180521044220.123933-1-joel@joelfernandes.org> <20180521044220.123933-4-joel@joelfernandes.org> <20180521231357.GI3803@linux.vnet.ibm.com> <20180522000016.GC40541@joelaf.mtv.corp.google.com> <20180522001925.GO3803@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180522001925.GO3803@linux.vnet.ibm.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 21, 2018 at 05:19:25PM -0700, Paul E. McKenney wrote: > On Mon, May 21, 2018 at 05:00:16PM -0700, Joel Fernandes wrote: > > On Mon, May 21, 2018 at 04:13:57PM -0700, Paul E. McKenney wrote: > > > > --- > > > > kernel/rcu/tree.c | 48 ++++++++++++++++++++++++----------------------- > > > > 1 file changed, 25 insertions(+), 23 deletions(-) > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > > > index 0ffd41ba304f..879c67a31116 100644 > > > > --- a/kernel/rcu/tree.c > > > > +++ b/kernel/rcu/tree.c > > > > @@ -1526,7 +1526,7 @@ static void trace_rcu_this_gp(struct rcu_node *rnp, struct rcu_data *rdp, > > > > > > > > /* > > > > * rcu_start_this_gp - Request the start of a particular grace period > > > > - * @rnp: The leaf node of the CPU from which to start. > > > > + * @rnp_start: The leaf node of the CPU from which to start. > > > > * @rdp: The rcu_data corresponding to the CPU from which to start. > > > > * @gp_seq_req: The gp_seq of the grace period to start. > > > > * > > > > @@ -1540,12 +1540,12 @@ static void trace_rcu_this_gp(struct rcu_node *rnp, struct rcu_data *rdp, > > > > * > > > > * Returns true if the GP thread needs to be awakened else false. > > > > */ > > > > -static bool rcu_start_this_gp(struct rcu_node *rnp, struct rcu_data *rdp, > > > > +static bool rcu_start_this_gp(struct rcu_node *rnp_start, struct rcu_data *rdp, > > > > unsigned long gp_seq_req) > > > > { > > > > bool ret = false; > > > > struct rcu_state *rsp = rdp->rsp; > > > > - struct rcu_node *rnp_root; > > > > + struct rcu_node *rnp, *rnp_root = NULL; > > > > > > Unless I am going blind, this patch really isn't using rnp_root. It > > > could be removed. > > > > Its just limitation of the diff tools. Your eyes are just fine and doing > > great based on your review comments ;) > > > > The rnp_root is used after we break out of the loop. > > > > > > > > > > /* > > > > * Use funnel locking to either acquire the root rcu_node > > > > @@ -1556,34 +1556,36 @@ static bool rcu_start_this_gp(struct rcu_node *rnp, struct rcu_data *rdp, > > > > * scan the leaf rcu_node structures. Note that rnp->lock must > > > > * not be released. > > > > */ > > > > - raw_lockdep_assert_held_rcu_node(rnp); > > > > - trace_rcu_this_gp(rnp, rdp, gp_seq_req, TPS("Startleaf")); > > > > - for (rnp_root = rnp; 1; rnp_root = rnp_root->parent) { > > > > - if (rnp_root != rnp) > > > > - raw_spin_lock_rcu_node(rnp_root); > > > > - if (ULONG_CMP_GE(rnp_root->gp_seq_needed, gp_seq_req) || > > > > - rcu_seq_started(&rnp_root->gp_seq, gp_seq_req) || > > > > - (rnp != rnp_root && > > > > - rcu_seq_state(rcu_seq_current(&rnp_root->gp_seq)))) { > > > > - trace_rcu_this_gp(rnp_root, rdp, gp_seq_req, > > > > + raw_lockdep_assert_held_rcu_node(rnp_start); > > > > + trace_rcu_this_gp(rnp_start, rdp, gp_seq_req, TPS("Startleaf")); > > > > + for (rnp = rnp_start; 1; rnp = rnp->parent) { > > > > + if (rnp != rnp_start) > > > > + raw_spin_lock_rcu_node(rnp); > > > > + if (ULONG_CMP_GE(rnp->gp_seq_needed, gp_seq_req) || > > > > + rcu_seq_started(&rnp->gp_seq, gp_seq_req) || > > > > + (rnp != rnp_start && > > > > + rcu_seq_state(rcu_seq_current(&rnp->gp_seq)))) { > > > > + trace_rcu_this_gp(rnp, rdp, gp_seq_req, > > > > TPS("Prestarted")); > > > > goto unlock_out; > > > > } > > > > - rnp_root->gp_seq_needed = gp_seq_req; > > > > - if (rcu_seq_state(rcu_seq_current(&rnp->gp_seq))) { > > > > + rnp->gp_seq_needed = gp_seq_req; > > > > + if (rcu_seq_state(rcu_seq_current(&rnp_start->gp_seq))) { > > > > > > The original had a performance bug, which is quite a bit more obvious > > > given the new names, so thank you for that! The above statement should > > > instead be as follows: > > > > > > if (rcu_seq_state(rcu_seq_current(&rnp->gp_seq))) { > > > > > > It does not make sense to keep checking the starting rcu_node because > > > changes to ->gp_seq happen first at the top of the tree. So we might > > > take an earlier exit by checking the current rnp instead of rechecking > > > rnp_start over and over. > > > > > > Please feel free to make this change, which is probably best as a separate > > > patch. That way this rename patch can remain a straightforward rename patch. > > > > Yes, sounds like a nice optimization and I'm glad my variable renaming helped > > ;) I feel I should have seen it too. I can make this change and send out > > with my next series as you suggest. > > > > > > /* > > > > * We just marked the leaf, and a grace period > > > > * is in progress, which means that rcu_gp_cleanup() > > > > * will see the marking. Bail to reduce contention. > > > > */ > > > > - trace_rcu_this_gp(rnp, rdp, gp_seq_req, > > > > + trace_rcu_this_gp(rnp_start, rdp, gp_seq_req, > > > > TPS("Startedleaf")); > > > > goto unlock_out; > > > > } > > > > - if (rnp_root != rnp && rnp_root->parent != NULL) > > > > - raw_spin_unlock_rcu_node(rnp_root); > > > > - if (!rnp_root->parent) > > > > + if (rnp != rnp_start && rnp->parent != NULL) > > > > + raw_spin_unlock_rcu_node(rnp); > > > > + if (!rnp->parent) { > > > > + rnp_root = rnp; > > > > > > Since rnp_root is otherwise unused in the new version, the above statement > > > can be dropped along with the "if" statement's braces and the declaration. > > > > Actually rnp_root is needed for tracing calls after we breakout of the loop. > > But at that point, rnp_root is equal to rnp, so rnp_root still isn't > really needed, correct? You are right. Sorry about that, so I'll change the tracepoints that follow to use rnp, as you suggested. thanks, - Joel