Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2617462imm; Wed, 16 May 2018 16:21:51 -0700 (PDT) X-Google-Smtp-Source: AB8JxZol25zZcqm7u3DdPI+1AdLft1o11Bp9XEhCI/e3Xe9hICzZM+eBXV8LOW8SdQEySCarzuzV X-Received: by 2002:a63:6447:: with SMTP id y68-v6mr2237941pgb.205.1526512911883; Wed, 16 May 2018 16:21:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526512911; cv=none; d=google.com; s=arc-20160816; b=ozrENIkcHnmWn4xNRLegXz8Rq2eyMHmE/KEt+CuFNvuCRHoM8f8ImE+80zE0YPDH4B GMHE6RvEXvS0E4yfvkDOOWaQVtVAaxN176K5DOhUm1uPkqhJn9/v+MBe9tBW6Ixkzdks udJjNDGK+zxq82HeBhn8FLyMbvuFMMT1nNBuwSE0EkRMQCrLH/207ea3ARc+jQr9ZxCw uCuhNvthAU3lMSd4gIrt9hmXJXFr+lZnaO21gIQCv5tQ7i3r0cDYUgx7JllyTKez/H26 yaekvKJQAoVu5Bb9Yxs81DGVEjbnD7dFXznxU2hSFRli1vTCIb5OglHXEVJPGzmCg6tA PrmQ== 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=6U9r26cjzCJv3+u8VvCJ293MChCfF/IXYys14WSpAFY=; b=GznQn1V3vQ2PFLsgBHWX1eS1tsJFBQMa8Siymg4e7nDU/NCiV3+9hML06ROxA1pcL1 UjXF6z0rL6giSYZs3yFcyRPBvXzitUQzhpEjvxNn7RjYsXzN8zIcyY3RsVJo5e3wyv/Z UWhsjGTC+q0CTg41gVX0tJSqYTfdV+P/tygjHXXQZtPfu2D6FQuAut08GB4Pl2D/m4uR BF1k9IdFYFSNWz8S6cvdiftwMvoikMhOZzd3OgiWoKPHxRRh5ATmcIo+2SkXnnCpcUKc jXpBZ8tVVTMT/dye6hxc1ycdB4iDFPEjJx8IgOhtqGUpg3YnUmjuXznJiS2Rheei8LpU dWcw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=DQMDTEp0; 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 n7-v6si2897860pgd.345.2018.05.16.16.21.34; Wed, 16 May 2018 16:21: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=DQMDTEp0; 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 S1751457AbeEPXV1 (ORCPT + 99 others); Wed, 16 May 2018 19:21:27 -0400 Received: from mail-pl0-f66.google.com ([209.85.160.66]:36111 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751013AbeEPXV0 (ORCPT ); Wed, 16 May 2018 19:21:26 -0400 Received: by mail-pl0-f66.google.com with SMTP id v24-v6so1316106plo.3 for ; Wed, 16 May 2018 16:21:26 -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=6U9r26cjzCJv3+u8VvCJ293MChCfF/IXYys14WSpAFY=; b=DQMDTEp0kpKXUja3nvm4DSiDCVYUpijx91xY++ssiRHI1gJSH+F1z+o9VlktqdLS0M 7wL1MnOxmJmLY3Mqta5h2b+GWhIrYomzNxck2eUOx5v3yUitjMuqy3sf9CXoVN1SldpC NtVj0zWNaoHUquLLcXTXyzgrDeI4P7dwIMWNw= 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=6U9r26cjzCJv3+u8VvCJ293MChCfF/IXYys14WSpAFY=; b=TWQNGqOk24/PprT2iGCIFHP3Cb+WId89uBmYk6JfTF7uUDsL5zObwp/no0zikKCSrp wQjd2jUaLV2rvZyR8vlPfMrTEE+v/zTMVjxl0qa8CPlBx8tSk3HzqjW6jC29MVSi55+e /nbQMSTufHUzXRuj9/NVK2eTqfJqY+Z1RfOcjN+ooNweUBwecgi6rL61TjiTjGrLf64q 2lnrnKLYoZ93gONdWCNNyztW4s9FN69p7rQHUSFjP6t3dV1P/i3zn9fM3G4ao0eJtoQT 9rfxGMSoA0QDvrwbMoyyhAW9cWylm5gEYA5LE0CLKiZEYE5YcHTGFQG5ZS2kzkGuZ2sE kP1g== X-Gm-Message-State: ALKqPwcHjm/axUmvGv6fqdBOpsM2eC2lDftZhAxLkSLGIb7YbxiJo9Mf 2Ashzz99kX/piAX4oCM6cF7jGw== X-Received: by 2002:a17:902:b94a:: with SMTP id h10-v6mr2874694pls.321.1526512885929; Wed, 16 May 2018 16:21:25 -0700 (PDT) Received: from localhost ([2620:0:1000:1600:3122:ea9c:d178:eb]) by smtp.gmail.com with ESMTPSA id j11-v6sm4126460pgq.83.2018.05.16.16.21.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 16 May 2018 16:21:25 -0700 (PDT) Date: Wed, 16 May 2018 16:21:24 -0700 From: Joel Fernandes To: "Paul E. McKenney" Cc: linux-kernel@vger.kernel.org, Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , byungchul.park@lge.com, kernel-team@android.com Subject: Re: [PATCH RFC 1/8] rcu: Add comment documenting how rcu_seq_snap works Message-ID: <20180516232124.GC221547@joelaf.mtv.corp.google.com> References: <20180514031541.67247-2-joel@joelfernandes.org> <20180514173816.GA26088@linux.vnet.ibm.com> <20180515015133.GH209519@joelaf.mtv.corp.google.com> <20180515035951.GB26088@linux.vnet.ibm.com> <20180515070243.GA55557@joelaf.mtv.corp.google.com> <20180515125507.GE26088@linux.vnet.ibm.com> <20180515184115.GC169754@joelaf.mtv.corp.google.com> <20180515190801.GM26088@linux.vnet.ibm.com> <20180515225509.GA7510@joelaf.mtv.corp.google.com> <20180516154543.GD3803@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180516154543.GD3803@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 Wed, May 16, 2018 at 08:45:43AM -0700, Paul E. McKenney wrote: [...] > > > > The code would be correct then, but one issue is it would shout out the > > > > 'Prestarted' tracepoint for 'c' when that's not really true.. > > > > > > > > rcu_seq_done(&rnp_root->gp_seq, c) > > > > > > > > translates to ULONG_CMP_GE(&rnp_root->gp_seq, c) > > > > > > > > which translates to the fact that c-1 completed. > > > > > > > > So in this case if rcu_seq_done returns true, then saying that c has been > > > > 'Prestarted' seems a bit off to me. It should be 'Startedleaf' or something > > > > since what we really are doing is just marking the leaf as you mentioned in > > > > the unlock_out part for a future start. > > > > > > Indeed, some of the tracing is not all that accurate. But the trace > > > message itself contains the information needed to work out why the > > > loop was exited, so perhaps something like 'EarlyExit'? > > > > I think since you're now using rcu_seq_start to determine if c has started or > > completed since, the current 'Prestarted' trace will cover it. > > "My work is done!" ;-) :-D Its cool how a conversation can turn into a code improvement. > > > ------------------------------------------------------------------------ > > > > > > commit 59a4f38edcffbef1521852fe3b26ed4ed85af16e > > > Author: Paul E. McKenney > > > Date: Tue May 15 11:53:41 2018 -0700 > > > > > > rcu: Make rcu_start_this_gp() check for grace period already started > > > > > > In the old days of ->gpnum and ->completed, the code requesting a new > > > grace period checked to see if that grace period had already started, > > > bailing early if so. The new-age ->gp_seq approach instead checks > > > whether the grace period has already finished. A compensating change > > > pushed the requested grace period down to the bottom of the tree, thus > > > reducing lock contention and even eliminating it in some cases. But why > > > not further reduce contention, especially on large systems, by doing both, > > > especially given that the cost of doing both is extremely small? > > > > > > This commit therefore adds a new rcu_seq_started() function that checks > > > whether a specified grace period has already started. It then uses > > > this new function in place of rcu_seq_done() in the rcu_start_this_gp() > > > function's funnel locking code. > > > > > > Reported-by: Joel Fernandes > > > Signed-off-by: Paul E. McKenney > > > > > > diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h > > > index 003671825d62..1c5cbd9d7c97 100644 > > > --- a/kernel/rcu/rcu.h > > > +++ b/kernel/rcu/rcu.h > > > @@ -108,6 +108,15 @@ static inline unsigned long rcu_seq_current(unsigned long *sp) > > > } > > > > > > /* > > > + * Given a snapshot from rcu_seq_snap(), determine whether or not the > > > + * corresponding update-side operation has started. > > > + */ > > > +static inline bool rcu_seq_started(unsigned long *sp, unsigned long s) > > > +{ > > > + return ULONG_CMP_LT((s - 1) & ~RCU_SEQ_STATE_MASK, READ_ONCE(*sp)); > > > +} > > > + > > > +/* > > > * Given a snapshot from rcu_seq_snap(), determine whether or not a > > > * full update-side operation has occurred. > > > */ > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > > index 9e900c5926cc..ed69f49b7054 100644 > > > --- a/kernel/rcu/tree.c > > > +++ b/kernel/rcu/tree.c > > > @@ -1580,7 +1580,7 @@ static bool rcu_start_this_gp(struct rcu_node *rnp, struct rcu_data *rdp, > > > if (rnp_root != rnp) > > > raw_spin_lock_rcu_node(rnp_root); > > > if (ULONG_CMP_GE(rnp_root->gp_seq_needed, c) || > > > - rcu_seq_done(&rnp_root->gp_seq, c) || > > > + rcu_seq_started(&rnp_root->gp_seq, c) || > > > > Yes, this does exactly what I was wanting, thanks! I think this puts our > > discussion about this to rest :-) > > > > By the way I was starting to beautify this loop like below last week, with > > code comments. I felt it would be easier to parse this loop in the future > > for whoever was reading it. Are you interested in such a patch? If not, let > > me know and I'll drop this and focus on the other changes you requested. > > > > Something like... (just an example , actual code would be different) > > > > for (rnp_node = rnp; 1; rnp_node = rnp_node->parent) { > > int prestarted = 0; > > > > /* Acquire lock if non-leaf node */ > > if (rnp_node != rnp) > > raw_spin_lock_rcu_node(rnp_node); > > > > /* Has the GP asked been recorded as a future need */ > > if (ULONG_CMP_GE(rnp_node->gp_seq_needed, gp_seq_start)) > > prestarted = 1; > > > > /* Has the GP requested for already been completed */ > > if (!prestarted && rcu_seq_completed(&rnp_node->gp_seq, gp_seq_start)) > > prestarted = 1; > > > > ... etc... > > if (prestarted) { > > trace_rcu_this_gp(rnp_node, rdp, gp_seq_start, > > TPS("Prestarted")); > > goto unlock_out; > > } > > At the moment, I don't believe that the extra lines of code pay for > themselves, but I do agree that this loop is a bit more obtuse than I > would like. Yeah I was also thinking the same. I'm glad I checked, thanks for the feedback. I'll focus on the other comments then. thanks, - Joel