Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp7214537imm; Sun, 20 May 2018 21:51:33 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqm2sn+gWqLyFbsFLwBPVFYZzlX+D0e/k/5l644YbmAW3eXwuwtv1N2ZFi1cuz/JPigTXjf X-Received: by 2002:a63:353:: with SMTP id 80-v6mr5497452pgd.178.1526878293627; Sun, 20 May 2018 21:51:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526878293; cv=none; d=google.com; s=arc-20160816; b=gx2v/uAxeldSi0xPpIjA8DKVdn98PgA8e+nAwdLoumDoSrSAEzrE7QETS86Suxx7Vw HaxB1IH7ajqZEsv7WzJCucxgnp+w/BfAdgfkLhhMbNzGyLlvTRA9IrcmfYlKGbyhx6hs a64HjdF1dPQoi4unZsyNgLUpHgVTCCBmjMhDSptQWr392LWbQ99nU+5FwngYwfAlOWjR JbB+rgOD6nlmJKu0Rv5gtWSww4ZBycBZRCDbuVqXT0g81xCMD+zSfZ1UMuUUWHcCIkec qLh5o/2vwhJPLu91FXpHUJtHpebSnOfbMZGoyDHtAzEOWEVYova0IgFqAdDx8UzwCRjz lMmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=8VDe2VUWyav7qU0d6K0cRp0TLqF0MeUV/oFpOiyY210=; b=AwQ5M1Td+52u3y91XABlMFy1Prs7DhUN9Ekv84+C5RB0Dt3s3RHOGRqdfsTa381hGk ZC/3NFbiAv/XuXWp4b4Yua/Lj8I9fq2y2gY8wZUTvsJhgJaE7tqUsLQJRFwDh+r44DMC eRiDJuXMq1ZvzYJvbQZUkIwErnzvJfOuj3y5ONovv7wMdcwCil0mpl02iqcg1JHkisEY Foa3XLvbnSAc1ejDfJppYOjeAKhffKeb9ohYgY8Lq1Y48V/zkIQmztcE66cp1uhkjNY4 6CR+WI/mZUwzINbqEe/l6/i56WacaL94Xok9q6++x9whWvoEq2GeImICoJsts4z8DtUq JCIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=WE2T4SnR; 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 s14-v6si12976784pfh.11.2018.05.20.21.51.19; Sun, 20 May 2018 21:51:33 -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=fail header.i=@infradead.org header.s=merlin.20170209 header.b=WE2T4SnR; 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 S1751127AbeEUEuz (ORCPT + 99 others); Mon, 21 May 2018 00:50:55 -0400 Received: from merlin.infradead.org ([205.233.59.134]:50378 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750849AbeEUEuy (ORCPT ); Mon, 21 May 2018 00:50:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8VDe2VUWyav7qU0d6K0cRp0TLqF0MeUV/oFpOiyY210=; b=WE2T4SnRwJ/7/9nIoLts3eYrS5 bXRXmJi4hlQw2WVh/0jipxsuKmu4eFZ50G42rYT3oldw+HJqjoMdIzNsHIJT1BxcSdbudhph6okzB CmlwRLUZCAb1+LXZjMLH0kwS4fJNfOBIvJZ89tK7kgmvkIEjsP4lS0HQELOnqflRam0iVvLMRaIo1 JAEZlqZLAVs2Kpu/F5Ps5lA26NVWkn0ZkJpkS95UxGmHV1qXZ1iyDpfdvJJRv+1B64zfkv8vC/cbI pjFEt/CXYTLG0NbwX4aSBE2MItUeWwSdc7DzNdYDQgpqe3JrhYKwIdyzg1gZJ98ua0u9QcsX9vcL5 lkzkOzVA==; Received: from static-50-53-52-16.bvtn.or.frontiernet.net ([50.53.52.16] helo=midway.dunlab) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fKcmB-0008IA-LM; Mon, 21 May 2018 04:50:27 +0000 Subject: Re: [PATCH v3 1/4] rcu: Add comment documenting how rcu_seq_snap works To: Joel Fernandes , linux-kernel@vger.kernel.org Cc: Joel Fernandes , "Paul E. McKenney" , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , byungchul.park@lge.com, kernel-team@android.com References: <20180521044220.123933-1-joel@joelfernandes.org> <20180521044220.123933-2-joel@joelfernandes.org> From: Randy Dunlap Message-ID: Date: Sun, 20 May 2018 21:50:25 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180521044220.123933-2-joel@joelfernandes.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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