Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933222AbcKQTQg (ORCPT ); Thu, 17 Nov 2016 14:16:36 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:46875 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751640AbcKQTQe (ORCPT ); Thu, 17 Nov 2016 14:16:34 -0500 Date: Thu, 17 Nov 2016 07:54:23 -0800 From: "Paul E. McKenney" To: Boqun Feng Cc: Lai Jiangshan , LKML , Ingo Molnar , dipankar@in.ibm.com, akpm@linux-foundation.org, Mathieu Desnoyers , Josh Triplett , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , David Howells , edumazet@google.com, dvhart@linux.intel.com, =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker , oleg@redhat.com, bobby.prani@gmail.com, ldr709@gmail.com Subject: Re: [PATCH RFC tip/core/rcu] SRCU rewrite Reply-To: paulmck@linux.vnet.ibm.com References: <20161114183636.GA28589@linux.vnet.ibm.com> <20161115014445.GC12110@tardis.cn.ibm.com> <20161115143700.GZ4127@linux.vnet.ibm.com> <20161117134957.GW3612@linux.vnet.ibm.com> <20161117143829.GA21600@linux.vnet.ibm.com> <20161117144544.GC5227@tardis.cn.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161117144544.GC5227@tardis.cn.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16111715-0004-0000-0000-000010E02490 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006094; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000189; SDB=6.00781987; UDB=6.00377288; IPR=6.00559491; BA=6.00004889; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013361; XFM=3.00000011; UTC=2016-11-17 15:54:27 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16111715-0005-0000-0000-00007AAA0822 Message-Id: <20161117155423.GA3612@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-17_09:,, 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-1611170282 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1994 Lines: 45 On Thu, Nov 17, 2016 at 10:45:44PM +0800, Boqun Feng wrote: > On Thu, Nov 17, 2016 at 06:38:29AM -0800, Paul E. McKenney wrote: > > On Thu, Nov 17, 2016 at 05:49:57AM -0800, Paul E. McKenney wrote: > > > On Thu, Nov 17, 2016 at 08:18:51PM +0800, Lai Jiangshan wrote: > > > > On Tue, Nov 15, 2016 at 10:37 PM, Paul E. McKenney > > > > wrote: > > > > > On Tue, Nov 15, 2016 at 09:44:45AM +0800, Boqun Feng wrote: > > > > > > > > >> > > > > >> __srcu_read_lock() used to be called with preemption disabled. I guess > > > > >> the reason was because we have two percpu variables to increase. So with > > > > >> only one percpu right, could we remove the preempt_{dis,en}able() in > > > > >> srcu_read_lock() and use this_cpu_inc() here? > > > > > > > > > > Quite possibly... > > > > > > > > > > > > > it will be nicer if it is removed. > > > > > > > > The reason for the preemption-disabled was also because we > > > > have to disallow any preemption between the fetching of the idx > > > > and the increasement. so that we have at most NR_CPUS worth > > > > of readers using the old index that haven't incremented the counters. > > > > > > > > if we remove the preempt_{dis,en}able(). we must change the > > > > "NR_CPUS" in the comment into ULONG_MAX/4. (I assume > > > > one on-going reader needs at least need 4bytes at the stack). it is still safe. > > > > > > > > but we still need to think more if we want to remove the preempt_{dis,en}able(). > > > > > > Good points! Agreed, any change in the preemption needs careful thought > > > and needs to be a separate patch. > > > > And one area needing special thought is the call to __srcu_read_lock() > > and __srcu_read_unlock() in do_exit(). > > > > So before commit 49f5903b473c5, we don't have the read of ->completed in > preemption disable section? > > And following "git blame", I found commit 7a6b55e7108b3 ;-) Thankfully the first (49f5903b473c5) came after the second. ;-) Thanx, Paul