Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp643289pxb; Thu, 19 Nov 2020 10:04:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJw1N+njAmZp1r6r7uxdJ9LAuLs84X1NxLUTI3iFG/NzmnxKHV7tzrkc7CLUWHZECBEANU86 X-Received: by 2002:a50:a6d0:: with SMTP id f16mr30800323edc.135.1605809046700; Thu, 19 Nov 2020 10:04:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605809046; cv=none; d=google.com; s=arc-20160816; b=Q6IVbBZsXBGcasYQfZb0lhsZBZlPT5P9KxhuiM1XCuC9QVwpA3Wc0NYLBYd4ngHn0h 5kNjmiucb1PXOjpx/NcQ/1kscDJneRquZ/4xfGOrULvM1Ki/1TcY4kw1302yXyw6X+d1 7AjZTjeNFVd9zjR5rzpoBjdQc7izRux5RWdAuE/mLvtpONJGSk/KdrQBB+9SFzX2CvG0 XISi6SVuvX9QnHHD3LKFg2LfB7cNSMXwbLGywLUyYAf2OgrWhSzLwdDuu9f91bbmkD56 t3IzHZwh/XHhqqcLV/qmuo/DZQePb02FSSVlypwdhtAE/GeEmcte9icElCKtV0ybDQWa B4+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=rg2tLaALto8jX1FS9h2sKXd+H11o1gDemlkjukEzTbo=; b=lICQacBx5+AteLypKcZij0vIdyzoidGia+cmIO1SE/M7g2Cjoks3zlo3Q6Gkev6LVW IapwZ2KBj6fob4FQMYHeuU2+v6A5p0jDtQPf5UcSmLPfgPcS+6QDPnhx/mz8P+4pPPfX TuC85DHRgBN5ejc1DOlapHfssl9TbEaCVzM9HopFq9aYoS+NBaiMvh3uvH99cfL2krhZ gmqp1qg+DPD6BlG9XS3JYer5OKnc8O/1cvJ/TIW87W6SQGPrizpEYnnrY/6GHGDE7COv 5Sk51PdxtOlJJfzKCNADEQ/CX/W8VEBjxeNZxgLnag4+ff0fyjCKnhtxfgdHbvNkFhHa Y5DA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=G9nXR0Hc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p14si239471ejg.51.2020.11.19.10.03.33; Thu, 19 Nov 2020 10:04:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=G9nXR0Hc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728262AbgKSSAO (ORCPT + 99 others); Thu, 19 Nov 2020 13:00:14 -0500 Received: from mail.kernel.org ([198.145.29.99]:60500 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727016AbgKSSAN (ORCPT ); Thu, 19 Nov 2020 13:00:13 -0500 Received: from paulmck-ThinkPad-P72.home (50-39-104-11.bvtn.or.frontiernet.net [50.39.104.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 84F15246A7; Thu, 19 Nov 2020 18:00:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605808812; bh=SgurXvzhl9QuPyBTLPJtG4Q6saSrCINScSXjZM3boiY=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=G9nXR0Hc81p1Wd9CZ7BRzEKbDyKZi+wK22E0R4lEabYjim1Vlj9WubIAWnrlyLNL9 KlPJD/PP1cy0I7JGaiMCjcWOh6toiVfGO7WtmJ4+Zq0EBBEPuqlfzoILasOMSWxtEf oA1dto0U+ndVH69mpzAq+Maanvjexn6Pe0BdQSU4= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id 28B3235225CF; Thu, 19 Nov 2020 10:00:12 -0800 (PST) Date: Thu, 19 Nov 2020 10:00:12 -0800 From: "Paul E. McKenney" To: Neeraj Upadhyay Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com, mingo@kernel.org, jiangshanlai@gmail.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com, oleg@redhat.com, joel@joelfernandes.org, rcu@vger.kernel.org Subject: Re: [PATCH RFC tip/core/rcu 1/5] srcu: Make Tiny SRCU use multi-bit grace-period counter Message-ID: <20201119180012.GW1437@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org References: <20201117004017.GA7444@paulmck-ThinkPad-P72> <20201117004052.14758-1-paulmck@kernel.org> <72dffe43-b746-6d75-1f6a-9936d709be63@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72dffe43-b746-6d75-1f6a-9936d709be63@codeaurora.org> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 19, 2020 at 01:44:49PM +0530, Neeraj Upadhyay wrote: > Hi Paul, > > On 11/17/2020 6:10 AM, paulmck@kernel.org wrote: > > From: "Paul E. McKenney" > > > > There is a need for a polling interface for SRCU grace periods. This > > polling needs to distinguish between an SRCU instance being idle on the > > one hand or in the middle of a grace period on the other. This commit > > therefore converts the Tiny SRCU srcu_struct structure's srcu_idx from > > a defacto boolean to a free-running counter, using the bottom bit to > > indicate that a grace period is in progress. The second-from-bottom > > bit is thus used as the index returned by srcu_read_lock(). > > > > Link: https://lore.kernel.org/rcu/20201112201547.GF3365678@moria.home.lan/ > > Reported-by: Kent Overstreet > > Signed-off-by: Paul E. McKenney > > --- > > include/linux/srcutiny.h | 4 ++-- > > kernel/rcu/srcutiny.c | 5 +++-- > > 2 files changed, 5 insertions(+), 4 deletions(-) > > > > diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h > > index 5a5a194..fed4a2d 100644 > > --- a/include/linux/srcutiny.h > > +++ b/include/linux/srcutiny.h > > @@ -15,7 +15,7 @@ > > struct srcu_struct { > > short srcu_lock_nesting[2]; /* srcu_read_lock() nesting depth. */ > > - short srcu_idx; /* Current reader array element. */ > > + unsigned short srcu_idx; /* Current reader array element in bit 0x2. */ > > u8 srcu_gp_running; /* GP workqueue running? */ > > u8 srcu_gp_waiting; /* GP waiting for readers? */ > > struct swait_queue_head srcu_wq; > > @@ -59,7 +59,7 @@ static inline int __srcu_read_lock(struct srcu_struct *ssp) > > { > > int idx; > > - idx = READ_ONCE(ssp->srcu_idx); > > + idx = (READ_ONCE(ssp->srcu_idx) & 0x2) / 2; > > Should we use bit 0x2 of (READ_ONCE(ssp->srcu_idx) + 1) , if GP > (srcu_drive_gp()) is in progress? Or am I missing something here? > > idx = ((READ_ONCE(ssp->srcu_idx) +1) & 0x2) / 2; You miss nothing! I am running about 200 hours of concurrent rcutorture of the SRCU-t and SRCU-u scenarios, but I must admit that this race could be hard to hit. But it could of course result in too-short grace periods. I will fold this into the original with attribution. > Also, any reason for using divison instead of shift; something to > do with 16-bit srcu_idx which I am missing here? I just figure that the compiler is better at selecting instructions than I am. Either would work. Thanx, Paul > Thanks > Neeraj > > > WRITE_ONCE(ssp->srcu_lock_nesting[idx], ssp->srcu_lock_nesting[idx] + 1); > > return idx; > > } > > diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c > > index 6208c1d..5598cf6 100644 > > --- a/kernel/rcu/srcutiny.c > > +++ b/kernel/rcu/srcutiny.c > > @@ -124,11 +124,12 @@ void srcu_drive_gp(struct work_struct *wp) > > ssp->srcu_cb_head = NULL; > > ssp->srcu_cb_tail = &ssp->srcu_cb_head; > > local_irq_enable(); > > - idx = ssp->srcu_idx; > > - WRITE_ONCE(ssp->srcu_idx, !ssp->srcu_idx); > > + idx = (ssp->srcu_idx & 0x2) / 2; > > + WRITE_ONCE(ssp->srcu_idx, ssp->srcu_idx + 1); > > WRITE_ONCE(ssp->srcu_gp_waiting, true); /* srcu_read_unlock() wakes! */ > > swait_event_exclusive(ssp->srcu_wq, !READ_ONCE(ssp->srcu_lock_nesting[idx])); > > WRITE_ONCE(ssp->srcu_gp_waiting, false); /* srcu_read_unlock() cheap. */ > > + WRITE_ONCE(ssp->srcu_idx, ssp->srcu_idx + 1); > > /* Invoke the callbacks we removed above. */ > > while (lh) { > > > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of > the Code Aurora Forum, hosted by The Linux Foundation