Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754020AbcKOO0e (ORCPT ); Tue, 15 Nov 2016 09:26:34 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:47952 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752186AbcKOO0c (ORCPT ); Tue, 15 Nov 2016 09:26:32 -0500 Date: Tue, 15 Nov 2016 06:26:27 -0800 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Mathieu Desnoyers , linux-kernel , Ingo Molnar , Lai Jiangshan , dipankar , Andrew Morton , Josh Triplett , Thomas Gleixner , rostedt , David Howells , Eric Dumazet , dvhart , fweisbec , Oleg Nesterov , bobby prani , ldr709 Subject: Re: [PATCH RFC tip/core/rcu] SRCU rewrite Reply-To: paulmck@linux.vnet.ibm.com References: <20161114183636.GA28589@linux.vnet.ibm.com> <20161115075113.GN3142@twins.programming.kicks-ass.net> <1857730044.1901.1479218090893.JavaMail.zimbra@efficios.com> <20161115135912.GJ3142@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161115135912.GJ3142@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16111514-0028-0000-0000-0000060A4ADD X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006082; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000189; SDB=6.00781017; UDB=6.00376694; IPR=6.00558525; BA=6.00004883; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013333; XFM=3.00000011; UTC=2016-11-15 14:26:30 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16111514-0029-0000-0000-000030DCBAF8 Message-Id: <20161115142627.GX4127@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-15_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611150258 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1502 Lines: 32 On Tue, Nov 15, 2016 at 02:59:12PM +0100, Peter Zijlstra wrote: > On Tue, Nov 15, 2016 at 01:54:50PM +0000, Mathieu Desnoyers wrote: > > ----- On Nov 15, 2016, at 2:51 AM, Peter Zijlstra peterz@infradead.org wrote: > > > > > On Mon, Nov 14, 2016 at 10:36:36AM -0800, Paul E. McKenney wrote: > > >> SRCU uses two per-cpu counters: a nesting counter to count the number of > > >> active critical sections, and a sequence counter to ensure that the nesting > > >> counters don't change while they are being added together in > > >> srcu_readers_active_idx_check(). > > >> > > >> This patch instead uses per-cpu lock and unlock counters. Because the both > > >> counters only increase and srcu_readers_active_idx_check() reads the unlock > > >> counter before the lock counter, this achieves the same end without having > > >> to increment two different counters in srcu_read_lock(). This also saves a > > >> smp_mb() in srcu_readers_active_idx_check(). > > > > > > A very small improvement... I feel SRCU has much bigger issues :/ > > > > Do you have specific issues in mind ? > > The smp_mb()s in read_{un,}lock() and the lock in call_srcu() come to > mind. There is some possibility of weakening the srcu_read_unlock() ordering, but one step at a time. Has the lock in call_srcu() been causing trouble? Easy to fix if so, but as you noted in another email today, we don't need complexity for complexity's sake. And no reports of problems with this have reached me thus far. Thanx, Paul