Message-Id: <1212618449.19205.35.camel@lappy.programming.kicks-ass.net>
Date:	Thu, 05 Jun 2008 00:27:29 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	Hideo AOKI <haoki@...hat.com>, mingo@...e.hu,
	Masami Hiramatsu <mhiramat@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Kernel marker has no performance impact on ia64.

On Mon, 2008-06-02 at 19:21 -0400, Mathieu Desnoyers wrote:
> * Peter Zijlstra (peterz@...radead.org) wrote:
> > On Mon, 2008-06-02 at 18:12 -0400, Hideo AOKI wrote:
> > > Hello,
> > > 
> > > I evaluated overhead of kernel marker using linux-2.6-sched-fixes
> > > git tree, which includes several markers for LTTng, using an ia64
> > > server.
> > > 
> > > While the immediate trace mark feature isn't implemented on ia64,
> > > there is no major performance regression. So, I think that we 
> > > don't have any issues to propose merging marker point patches 
> > > into Linus's tree from the viewpoint of performance impact.
> > 
> > Performance is atm the least of the concerns regarding this work.
> > 
> > I'm still convinced markers are too ugly to live.
> > 
> > I also worry greatly about the fact that its too easy to expose too much
> > to user-space. There are no clear rules and the free form marker format
> > just begs for an inconsistent mess to arise.
> > 
> > IMHO the current free-form trace_mark() should be removed from the tree
> > - its great for ad-hoc debugging but its a disaster waiting to happen
> > for anything else. Anybody doing ad-hoc debugging can patch it in
> > themselves if needed.
> > 
> > Regular trace points can be custom made; this has the advantages that it
> > raises the implementation barrier and hopefully that encourages some
> > thought in the process. It also avoid the code from growing into
> > something that looks like someone had a long night of debugging.
> > 
> 
> Maybe we could settle for an intermediate solution : I agree with you
> that defining the trace points in headers, like you did for the
> scheduler, makes the code much cleaner and makes things much easier to
> maintain afterward. However, having the trace_mark mechanism underneath
> helps a lot in plugging a generic tracer (actually, if we can settle the
> marker issue, I've got a kernel tracer, LTTng, that I've been waiting
> for quite a while to push to mainline that I would like to post someday).
> 
> So I would be in favor of requiring tracing statements to be described
> in static inline functions, in header files, that could preferably call
> trace_mark() and optionally also call other in-kernel tracers directly.
> 
> Ideally, we could re-use the immediate values infrastructure to control
> activation of these trace points with minimal impact on the system.
> 
> One of my goal is to provide a mechanism that can feed both non-debug
> and debug information to a generic tracing mechanism to allow
> system-wide analysis of the kernel, both for production system and
> kernel debugging.

So are you proposing something like:

static inline void 
trace_sched_switch(struct task_struct *prev, struct task_struct *next)
{
	trace_mark(sched_switch, prev, next);
}

dropping the silly fmt string but using the multiplex of trace_mark, and
then doing the stringify bit:

       "prev_pid %d next_pid %d prev_state %ld\n"

in the actual tracer?


IMHO the 'type safety' of the fmt string is over-rated, since it cannot
distinguish between a task_struct * or a bio *, both are a pointers -
and half arsed type safely is worse than no type safety.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists