Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932285AbWIPAnU (ORCPT ); Fri, 15 Sep 2006 20:43:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932284AbWIPAnU (ORCPT ); Fri, 15 Sep 2006 20:43:20 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]:55955 "EHLO sccrmhc14.comcast.net") by vger.kernel.org with ESMTP id S932285AbWIPAnT (ORCPT ); Fri, 15 Sep 2006 20:43:19 -0400 Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108 From: Nicholas Miell To: Ingo Molnar Cc: Roman Zippel , Thomas Gleixner , karim@opersys.com, Andrew Morton , Paul Mundt , Jes Sorensen , Mathieu Desnoyers , linux-kernel@vger.kernel.org, Christoph Hellwig , Ingo Molnar , Greg Kroah-Hartman , Tom Zanussi , ltt-dev@shafik.org, Michel Dagenais In-Reply-To: <20060915235707.GB29929@elte.hu> References: <1158348954.5724.481.camel@localhost.localdomain> <450B0585.5070700@opersys.com> <1158351780.5724.507.camel@localhost.localdomain> <20060915204812.GA6909@elte.hu> <20060915215112.GB12789@elte.hu> <20060915231419.GA24731@elte.hu> <1158364161.2352.9.camel@entropy> <20060915235707.GB29929@elte.hu> Content-Type: text/plain Date: Fri, 15 Sep 2006 17:41:22 -0700 Message-Id: <1158367282.2352.18.camel@entropy> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5.0.njm.1) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2188 Lines: 52 On Sat, 2006-09-16 at 01:57 +0200, Ingo Molnar wrote: > * Nicholas Miell wrote: > > > You're going to want to be able to trace every function in the kernel, > > which means they'd all need a __trace -- and in that case, a > > -fpad-functions-for-tracing gcc option would make more sense then > > per-function attributes. > > the __trace attribute would be a _specific_ replacement for a _specific_ > static markup at the entry of a function. So no, we would not want to > add __trace to _every_ function in the kernel: only those which get > commonly traced. And note that SystemTap can trace the rest too, just > with slighly higher overhead. > > In that sense __trace is not an enabling infrastructure, it's a > performance tuning infrastructure. > > > The option could also insert NOPs before RETs, not just before the > > prologue so that function returns are equally easy to trace. (It might > > also inhibit tail calls, assuming being able to trace all function > > returns is more important than that optimization.) > > yeah. __trace_entry and __trace_exit [or both] attributes. Makes sense. > > > And SystemTap can already hook into sock_sendmsg() (or any other > > function) and examine it's arguments -- all of this GCC extension talk > > is just performance enhancement. > > yes, yes, yes, exactly!!! Finally someone reads my mails and understands > my points. There's hope! ;) I'm not sure that I do, actually. You seem to be opposed to all static probe markers in general, but I think that they'd be useful for big abstract things like "new thread created" (which would encompass fork/vfork/clone and probably consist of a single marker in do_fork) or for similar things that happen all over the kernel (for example, I imagine that all filesystems would want to use the same set of probe names just to make I/O tracing easier for userspace). -- Nicholas Miell - 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/