Messages in this thread | | | Subject | Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108 | From | Nicholas Miell <> | Date | Fri, 15 Sep 2006 17:41:22 -0700 |
| |
On Sat, 2006-09-16 at 01:57 +0200, Ingo Molnar wrote: > * Nicholas Miell <nmiell@comcast.net> 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 <nmiell@comcast.net>
- 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/
| |