From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753427AbbEFFlx (ORCPT ); Wed, 6 May 2015 01:41:53 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:41842 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752127AbbEFFlv (ORCPT ); Wed, 6 May 2015 01:41:51 -0400 Date: Tue, 5 May 2015 22:41:46 -0700 From: "Paul E. McKenney" To: Rik van Riel Cc: Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Andy Lutomirski , "linux-kernel@vger.kernel.org" , X86 ML , williams@redhat.com, Andrew Lutomirski , fweisbec@redhat.com, Heiko Carstens , Thomas Gleixner , Ingo Molnar , Linus Torvalds Subject: Re: question about RCU dynticks_nesting Message-ID: <20150506054146.GY5381@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150502052733.GA9983@gmail.com> <55473B47.6080600@redhat.com> <55479749.7070608@redhat.com> <5547C1DC.10802@redhat.com> <20150504193923.GX5381@linux.vnet.ibm.com> <20150505105346.GJ21418@twins.programming.kicks-ass.net> <20150505123446.GN5381@linux.vnet.ibm.com> <20150505130026.GM21418@twins.programming.kicks-ass.net> <20150505183556.GS5381@linux.vnet.ibm.com> <55493183.2070201@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55493183.2070201@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15050605-8236-0000-0000-00000B41760C Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 05, 2015 at 05:09:23PM -0400, Rik van Riel wrote: > On 05/05/2015 02:35 PM, Paul E. McKenney wrote: > > On Tue, May 05, 2015 at 03:00:26PM +0200, Peter Zijlstra wrote: > >> On Tue, May 05, 2015 at 05:34:46AM -0700, Paul E. McKenney wrote: > >>> On Tue, May 05, 2015 at 12:53:46PM +0200, Peter Zijlstra wrote: > >>>> On Mon, May 04, 2015 at 12:39:23PM -0700, Paul E. McKenney wrote: > >>>>> But in non-preemptible RCU, we have PREEMPT=n, so there is no preempt > >>>>> counter in production kernels. Even if there was, we have to sample this > >>>>> on other CPUs, so the overhead of preempt_disable() and preempt_enable() > >>>>> would be where kernel entry/exit is, so I expect that this would be a > >>>>> net loss in overall performance. > >>>> > >>>> We unconditionally have the preempt_count, its just not used much for > >>>> PREEMPT_COUNT=n kernels. > >>> > >>> We have the field, you mean? I might be missing something, but it still > >>> appears to me thta preempt_disable() does nothing for PREEMPT=n kernels. > >>> So what am I missing? > >> > >> There's another layer of accessors that can in fact manipulate the > >> preempt_count even for !PREEMPT_COUNT kernels. They are currently used > >> by things like pagefault_disable(). > > > > OK, fair enough. > > > > I am going to focus first on getting rid of (or at least greatly reducing) > > RCU's interrupt disabling on the user-kernel entry/exit paths, since > > that seems to be the biggest cost. > > Interrupts are already disabled on kernel-user and kernel-guest > switches. Paolo and I have patches to move a bunch of the calls > to user_enter, user_exit, guest_enter, and guest_exit to places > where interrupts are already disabled, so we do not need to > disable them again. > > With those in place, the vtime calculations are the largest > CPU user. I am working on those. OK, so I should stop worrying about making rcu_user_enter() and rcu_user_exit() operate with interrupts disabled, and instead think about the overhead of the operations themselves. Probably starting from Mike Galbraith's profile (thank you!) unless Rik has some reason to believe that it is nonrepresentative. Thanx, Paul