From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756292AbbIUUno (ORCPT ); Mon, 21 Sep 2015 16:43:44 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:54737 "EHLO e36.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752634AbbIUUnm (ORCPT ); Mon, 21 Sep 2015 16:43:42 -0400 X-Helo: d03dlp02.boulder.ibm.com X-MailFrom: paulmck@linux.vnet.ibm.com X-RcptTo: linux-kernel@vger.kernel.org Date: Mon, 21 Sep 2015 13:43:27 -0700 From: "Paul E. McKenney" To: Frederic Weisbecker Cc: Boqun Feng , Fengguang Wu , LKP , LKML Subject: Re: [rcu] kernel BUG at include/linux/pagemap.h:149! Message-ID: <20150921204327.GH4029@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150910005708.GA23369@wfg-t540p.sh.intel.com> <20150910102513.GA1677@fixme-laptop.cn.ibm.com> <20150910171649.GE4029@linux.vnet.ibm.com> <20150911021933.GA1521@fixme-laptop.cn.ibm.com> <20150921193045.GA13674@lerouge> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150921193045.GA13674@lerouge> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15092120-0021-0000-0000-000013040BF4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 21, 2015 at 09:30:49PM +0200, Frederic Weisbecker wrote: > On Fri, Sep 11, 2015 at 10:19:47AM +0800, Boqun Feng wrote: > > Subject: [PATCH 01/27] rcu: Don't disable preemption for Tiny and Tree RCU > > readers > > > > Because preempt_disable() maps to barrier() for non-debug builds, > > it forces the compiler to spill and reload registers. Because Tree > > RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these > > barrier() instances generate needless extra code for each instance of > > rcu_read_lock() and rcu_read_unlock(). This extra code slows down Tree > > RCU and bloats Tiny RCU. > > > > This commit therefore removes the preempt_disable() and preempt_enable() > > from the non-preemptible implementations of __rcu_read_lock() and > > __rcu_read_unlock(), respectively. > > > > For debug purposes, preempt_disable() and preempt_enable() are still > > kept if CONFIG_PREEMPT_COUNT=y, which makes the detection of sleeping > > inside atomic sections still work in non-preemptible kernels. > > > > Signed-off-by: Boqun Feng > > Signed-off-by: Paul E. McKenney > > --- > > include/linux/rcupdate.h | 6 ++++-- > > include/linux/rcutiny.h | 1 + > > kernel/rcu/tree.c | 9 +++++++++ > > 3 files changed, 14 insertions(+), 2 deletions(-) > > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > > index d63bb77..6c3cece 100644 > > --- a/include/linux/rcupdate.h > > +++ b/include/linux/rcupdate.h > > @@ -297,12 +297,14 @@ void synchronize_rcu(void); > > > > static inline void __rcu_read_lock(void) > > { > > - preempt_disable(); > > + if (IS_ENABLED(CONFIG_PREEMPT_COUNT)) > > + preempt_disable(); > > preempt_disable() is a no-op when !CONFIG_PREEMPT_COUNT, right? > Or rather it's a barrier(), which is anyway implied by rcu_read_lock(). > > So perhaps we can get rid of the IS_ENABLED() check? Actually, barrier() is not intended to be implied by rcu_read_lock(). In a non-preemptible RCU implementation, it doesn't help anything to have the compiler flush its temporaries upon rcu_read_lock() and rcu_read_unlock(). Thanx, Paul