Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933312AbbHLBCi (ORCPT ); Tue, 11 Aug 2015 21:02:38 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:59475 "EHLO e36.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932485AbbHLBCg (ORCPT ); Tue, 11 Aug 2015 21:02:36 -0400 X-Helo: d03dlp01.boulder.ibm.com X-MailFrom: paulmck@linux.vnet.ibm.com X-RcptTo: linux-tip-commits@vger.kernel.org Date: Tue, 11 Aug 2015 18:02:29 -0700 From: "Paul E. McKenney" To: Andy Lutomirski Cc: Frederic Weisbecker , Denys Vlasenko , Rik van Riel , Borislav Petkov , Peter Zijlstra , Brian Gerst , Denys Vlasenko , Kees Cook , Thomas Gleixner , Oleg Nesterov , Andrew Lutomirski , Linus Torvalds , Ingo Molnar , "H. Peter Anvin" , "linux-kernel@vger.kernel.org" , "linux-tip-commits@vger.kernel.org" Subject: Re: [tip:x86/asm] x86/asm/entry/64: Migrate error and IRQ exit work to C and remove old assembly code Message-ID: <20150812010229.GL3895@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <60e90901eee611e59e958bfdbbe39969b4f88fe5.1435952415.git.luto@kernel.org> <20150811221822.GA15639@lerouge> <20150811224905.GC15639@lerouge> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15081201-0021-0000-0000-00000F2236C0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2667 Lines: 57 On Tue, Aug 11, 2015 at 03:59:37PM -0700, Andy Lutomirski wrote: > On Tue, Aug 11, 2015 at 3:49 PM, Frederic Weisbecker wrote: > > On Tue, Aug 11, 2015 at 03:25:04PM -0700, Andy Lutomirski wrote: > >> Can you explain to me what context tracking does that rcu_irq_enter > >> and vtime_account_irq_enter don't do that's expensive? Frankly, I'd > >> rather drop everything except the context tracking callback. > > > > Irqs have their own hooks in the generic code. irq_enter() and irq_exit(). > > And those take care of RCU and time accounting already. So arch code really > > doesn't need to care about that. > > I'd love to have irq_enter_from_user and irq_enter_from_kernel instead. RCU would need to know about irq_enter_from_user(), but could blithely ignore irq_enter_from_kernel(). Unless irq_enter_from_kernel() is called from the idle loop, in which case RCU would need to know. All that aside, the overhead of rcu_irq_enter() when called from non-idle kernel mode should be relatively small. So just telling RCU about all the interrupts is actually not a bad strategy. > > context tracking exists for the sole purpose of tracking states that don't > > have generic hooks. Those are syscalls and exceptions. > > > > Besides, rcu_user_exit() is more costly than rcu_irq_enter() which have been > > designed for the very purpose of providing a fast RCU tracking for non sleepable > > code (which needs rcu_user_exit()). > > So rcu_user_exit is slower because it's okay to sleep after calling it? > > Would it be possible to defer the overhead until we actually try to > sleep rather than doing it on entry? (I have no idea what's going on > under the hood.) Nor do I, at least not until someone tells me what .config they are using. NO_HZ_FULL, NO_HZ_FULL_SYSIDLE, and RCU_FAST_NO_HZ make a difference in this case. > Anyway, irq_enter_from_user would solve this problem completely. > > > > > I've been thinking about pushing down syscalls and exceptions to generic > > handlers. It might work for syscalls btw. But many exceptions have only > > arch handlers, or significant amount of work is done on the arch level > > which might make use of RCU (eg: breakpoint handlers on x86). > > I'm trying to port the meat of the x86 syscall code to C. Maybe the > result will generalize. The exit code is already in C (in -tip). That does sound like a good thing! Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/