Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp894801imm; Mon, 21 May 2018 16:42:47 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoyZkS81EyeqhmE2WuAzHJ41TGVQsaJRBXIEWpQMjfImALQVW7xXycFEpoUAVdkG2rQ9CNm X-Received: by 2002:a17:902:7406:: with SMTP id g6-v6mr21644352pll.237.1526946167122; Mon, 21 May 2018 16:42:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526946167; cv=none; d=google.com; s=arc-20160816; b=yRrOPLORM8inHh1TEI4blP8KxPKTasrhGERpqVzP2SFP+0CCmTkvbBLyVfoF5115YS RfeCa+4oR0C0Y3ByzM+LVlmwlQJTUDvKKEumT3PjLAZ4e8RRqoJcRsmqN1x4xqzYvx54 xrwURehQaNnj6j3H9lN16UWmHKYc4IicUjal1H4XvUURkej0I1GjX/NSJQExjumBDa5w d5m7empVayJq5rkqiHyKi8/Fo0vdwdZ0S5shSh5a+vqsUrIUswNRL71eLlgvwm5UE03A Ua1vwf/0UwFewzBjsuGvsxfinKlsN6c55aeydLn++BK7VF+FIODnkbCnUQHNc5kvmyTG mrFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:subject:cc:to :from:date:arc-authentication-results; bh=RBgnAbJU06jnvITAe8/qnKD1IbV6aWexzNtkIIBm1xE=; b=dxxzZCoi51kqt3UVVmCvaa3YztJtg4ix7NByAJhPyYJe+j8zMAPVcmD7ofdFtZLzGL fzbl3griFeEMg8ayjr4uHKMIvSw5GxBA9qxH5tmgVWhaxbAiBBV+XHkLBCiCxx7CsXFP NO4LvFzXCBUE/qJ9o11/BhZctqENzcXiyh2Pq3o8d9YSfc9OUkxCqvmBZ4hUa+Ii7nkh W91oZCvKX8haZhoSQvyKpCgRhws/YjOuYTAPlC7IrEvdwm3txiRKqWS7ku3oHkzqQLUd 7wPMcf1Om9UBDxveAVhqsed6LeDa9W6S8L7WS/Ir43JEHidLwtTJeK0MZBP4JARE8nfo yJqA== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m10-v6si1379799pgv.513.2018.05.21.16.42.32; Mon, 21 May 2018 16:42:47 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751571AbeEUXlU (ORCPT + 99 others); Mon, 21 May 2018 19:41:20 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:59054 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751195AbeEUXlT (ORCPT ); Mon, 21 May 2018 19:41:19 -0400 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4LNdwW8073716 for ; Mon, 21 May 2018 19:41:19 -0400 Received: from e15.ny.us.ibm.com (e15.ny.us.ibm.com [129.33.205.205]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j42xnjvmr-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 21 May 2018 19:41:18 -0400 Received: from localhost by e15.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 21 May 2018 19:41:18 -0400 Received: from b01cxnp22036.gho.pok.ibm.com (9.57.198.26) by e15.ny.us.ibm.com (146.89.104.202) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 21 May 2018 19:41:15 -0400 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4LNfEG355115968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 21 May 2018 23:41:14 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1FD0EB2065; Mon, 21 May 2018 20:43:05 -0400 (EDT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E3561B205F; Mon, 21 May 2018 20:43:04 -0400 (EDT) Received: from paulmck-ThinkPad-W541 (unknown [9.70.82.108]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 21 May 2018 20:43:04 -0400 (EDT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id E4CC716C3FC8; Mon, 21 May 2018 16:42:50 -0700 (PDT) Date: Mon, 21 May 2018 16:42:50 -0700 From: "Paul E. McKenney" To: Joel Fernandes Cc: Randy Dunlap , 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 1/4] rcu: Add comment documenting how rcu_seq_snap works Reply-To: paulmck@linux.vnet.ibm.com References: <20180521044220.123933-1-joel@joelfernandes.org> <20180521044220.123933-2-joel@joelfernandes.org> <20180521054826.GA137980@joelaf.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180521054826.GA137980@joelaf.mtv.corp.google.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18052123-0036-0000-0000-000002F85118 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009063; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000261; SDB=6.01035746; UDB=6.00529795; IPR=6.00814874; MB=3.00021229; MTD=3.00000008; XFM=3.00000015; UTC=2018-05-21 23:41:18 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18052123-0037-0000-0000-0000446A2684 Message-Id: <20180521234250.GM3803@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-21_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805210270 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 20, 2018 at 10:48:26PM -0700, Joel Fernandes wrote: > On Sun, May 20, 2018 at 09:50:25PM -0700, Randy Dunlap wrote: > > On 05/20/2018 09:42 PM, Joel Fernandes wrote: > > > rcu_seq_snap may be tricky to decipher. Lets document how it works with > > > an example to make it easier. > > > > > > Signed-off-by: Joel Fernandes (Google) > > > --- > > > kernel/rcu/rcu.h | 33 ++++++++++++++++++++++++++++++++- > > > 1 file changed, 32 insertions(+), 1 deletion(-) > > > > > > diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h > > > index 0453a7d12b3f..d4396c96f614 100644 > > > --- a/kernel/rcu/rcu.h > > > +++ b/kernel/rcu/rcu.h > > > @@ -91,7 +91,38 @@ static inline void rcu_seq_end(unsigned long *sp) > > > WRITE_ONCE(*sp, rcu_seq_endval(sp)); > > > } > > > > > > -/* Take a snapshot of the update side's sequence number. */ > > > +/* > > > + * rcu_seq_snap - Take a snapshot of the update side's sequence number. > > > + * > > > + * This function returns the earliest value of the grace-period sequence number > > > + * that will indicate that a full grace period has elapsed since the current > > > + * time. Once the grace-period sequence number has reached this value, it will > > > + * be safe to invoke all callbacks that have been registered prior to the > > > + * current time. This value is the current grace-period number plus two to the > > > + * power of the number of low-order bits reserved for state, then rounded up to > > > + * the next value in which the state bits are all zero. > > > + * > > > + * For example, since RCU_SEQ_STATE_MASK=3 and the least significant bit of > > > + * the seq is used to track if a GP is in progress or not, its sufficient if we > > > > it's > > > > > + * add (6+1) and mask with ~3 to get the next GP. Let's see why with an example: > > > + * > > > + * Say the current seq is 12 which is 0b1100 (GP is 3 and state bits are 0b00). > > > + * To get to the next GP number of 4, we have to add 0b100 to this (0x1 << 2) > > > + * to account for the shift due to 2 state bits. Now, if the current seq is > > > + * 13 (GP is 3 and state bits are 0b01), then it means the current grace period > > > + * is already in progress so the next GP that a future call back will be queued > > > + * to run at is GP+2 = 5, not 4. To account for the extra +1, we just overflow > > > + * the 2 lower bits by adding 0b11. Incase the lower bit was set, the overflow > > > > In case > > > > > + * will cause the extra +1 to the GP, along with the usual +1 explained before. > > > + * This gives us GP+2. Finally we mask the lower to bits by ~0x3 incase the > > > > in case > > > > > + * overflow didn't occur. This masking is needed because incase RCU was idle > > > > in case > > > > > + * (no GP in progress so lower 2 bits are 0b00), then the overflow of the lower > > > + * 2 state bits wouldn't occur, so we mask to zero out those lower 2 bits. > > > + * > > > + * In other words, the next seq can be obtained by (0b11 + 0b100) & (~0b11) > > > + * which can be generalized to: > > > + * seq + (RCU_SEQ_STATE_MASK + (RCU_SEQ_STATE_MASK + 1)) & (~RCU_SEQ_STATE_MASK) > > > + */ > > > static inline unsigned long rcu_seq_snap(unsigned long *sp) > > > { > > > unsigned long s; > > > > > > > cheers. > > -- > > ~Randy > > Thanks Randy. Fixed, updated patch below. Paul, let me know if you want > me to send it separately or if you can pick it up from below. > > Also I realize I need some better automated tools to catch these issues > (spelling errors in commit, diffs etc). Probably checkpatch.pl should > have such checks for these common things too. Indeed it does! Please resend this with the updated rnp_start patch, with the additional change noted by Randy. Or just change to "it is", which allows you to have one less situation where you need to worry about the apostrophes. Thanx, Paul > ----------8<---------- > > >From 1c1f8ce04bca656a3c07e555048545d4a59e44cf Mon Sep 17 00:00:00 2001 > From: Joel Fernandes > Date: Sun, 20 May 2018 19:37:18 -0700 > Subject: [PATCH v3.5] rcu: Add comment documenting how rcu_seq_snap works > > rcu_seq_snap may be tricky to decipher. Lets document how it works with > an example to make it easier. > > Signed-off-by: Joel Fernandes (Google) > --- > kernel/rcu/rcu.h | 33 ++++++++++++++++++++++++++++++++- > 1 file changed, 32 insertions(+), 1 deletion(-) > > diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h > index 0453a7d12b3f..00df3da98317 100644 > --- a/kernel/rcu/rcu.h > +++ b/kernel/rcu/rcu.h > @@ -91,7 +91,38 @@ static inline void rcu_seq_end(unsigned long *sp) > WRITE_ONCE(*sp, rcu_seq_endval(sp)); > } > > -/* Take a snapshot of the update side's sequence number. */ > +/* > + * rcu_seq_snap - Take a snapshot of the update side's sequence number. > + * > + * This function returns the earliest value of the grace-period sequence number > + * that will indicate that a full grace period has elapsed since the current > + * time. Once the grace-period sequence number has reached this value, it will > + * be safe to invoke all callbacks that have been registered prior to the > + * current time. This value is the current grace-period number plus two to the > + * power of the number of low-order bits reserved for state, then rounded up to > + * the next value in which the state bits are all zero. > + * > + * For example, since RCU_SEQ_STATE_MASK=3 and the least significant bit of > + * the seq is used to track if a GP is in progress or not, its sufficient if we > + * add (6+1) and mask with ~3 to get the next GP. Let's see why with an example: > + * > + * Say the current seq is 12 which is 0b1100 (GP is 3 and state bits are 0b00). > + * To get to the next GP number of 4, we have to add 0b100 to this (0x1 << 2) > + * to account for the shift due to 2 state bits. Now, if the current seq is > + * 13 (GP is 3 and state bits are 0b01), then it means the current grace period > + * is already in progress so the next GP that a future call back will be queued > + * to run at is GP+2 = 5, not 4. To account for the extra +1, we just overflow > + * the 2 lower bits by adding 0b11. In case the lower bit was set, the overflow > + * will cause the extra +1 to the GP, along with the usual +1 explained before. > + * This gives us GP+2. Finally we mask the lower to bits by ~0x3 in case the > + * overflow didn't occur. This masking is needed because in case RCU was idle > + * (no GP in progress so lower 2 bits are 0b00), then the overflow of the lower > + * 2 state bits wouldn't occur, so we mask to zero out those lower 2 bits. > + * > + * In other words, the next seq can be obtained by (0b11 + 0b100) & (~0b11) > + * which can be generalized to: > + * seq + (RCU_SEQ_STATE_MASK + (RCU_SEQ_STATE_MASK + 1)) & (~RCU_SEQ_STATE_MASK) > + */ > static inline unsigned long rcu_seq_snap(unsigned long *sp) > { > unsigned long s; > -- > 2.17.0.441.gb46fe60e1d-goog >