Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754591Ab3HETJt (ORCPT ); Mon, 5 Aug 2013 15:09:49 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:19975 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753623Ab3HETJs (ORCPT ); Mon, 5 Aug 2013 15:09:48 -0400 X-Authority-Analysis: v=2.0 cv=KJ7Y/S5o c=1 sm=0 a=Sro2XwOs0tJUSHxCKfOySw==:17 a=Drc5e87SC40A:10 a=pFOAptgLnqcA:10 a=5SG0PmZfjMsA:10 a=IkcTkHD0fZMA:10 a=meVymXHHAAAA:8 a=KGjhK52YXX0A:10 a=pvQ05lsfB1wA:10 a=GW_EKYI4TXm8SUCMv1EA:9 a=QEXdDO2ut3YA:10 a=Sro2XwOs0tJUSHxCKfOySw==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 67.255.60.225 Message-ID: <1375729786.22073.133.camel@gandalf.local.home> Subject: Re: [RFC] gcc feature request: Moving blocks into sections From: Steven Rostedt To: "H. Peter Anvin" Cc: Linus Torvalds , LKML , gcc , Ingo Molnar , Mathieu Desnoyers , Thomas Gleixner , David Daney , Behan Webster , Peter Zijlstra , Herbert Xu Date: Mon, 05 Aug 2013 15:09:46 -0400 In-Reply-To: <51FFF430.1060701@linux.intel.com> References: <1375721715.22073.80.camel@gandalf.local.home> <1375725328.22073.101.camel@gandalf.local.home> <51FFEC56.6040206@linux.intel.com> <1375727010.22073.110.camel@gandalf.local.home> <51FFEEEC.5060902@linux.intel.com> <1375728583.22073.118.camel@gandalf.local.home> <51FFF430.1060701@linux.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1338 Lines: 39 On Mon, 2013-08-05 at 11:51 -0700, H. Peter Anvin wrote: > On 08/05/2013 11:49 AM, Steven Rostedt wrote: > > On Mon, 2013-08-05 at 11:29 -0700, H. Peter Anvin wrote: > > > >> Traps nest, that's why there is a stack. (OK, so you don't want to take > >> the same trap inside the trap handler, but that code should be very > >> limited.) The trap instruction just becomes very short, but rather > >> slow, call-return. > >> > >> However, when you consider the cost you have to consider that the > >> tracepoint is doing other work, so it may very well amortize out. > > > > Also, how would you pass the parameters? Every tracepoint has its own > > parameters to pass to it. How would a trap know what where to get "prev" > > and "next"? > > > > How do you do that now? > > You have to do an IP lookup to find out what you are doing. ?? You mean to do the enabling? Sure, but not after the code is enabled. There's no lookup. It just calls functions directly. > > (Note: I wonder how much the parameter generation costs the tracepoints.) The same as doing a function call. -- Steve -- 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/