Re: Kernel marker has no performance impact on ia64.

[Masami Hiramatsu]

Hi Mathieu,

Mathieu Desnoyers wrote:
>>> 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).
>> That's good to me.
>> BTW, I'd like to know your plan, would those static inline functions be
>> defined in new headers or marker.h(or other existing headers)?
>>
> 
> Hi Masami,
> 
> What do you think of kernel/sched-trace.h for the scheduler as proposed
> by Peter ? Having these headers close to the c file instrumentation they
> deal with seems to scale maintenance better. Placing all these in one
> big kernel header included everywhere would require to recompile the
> whole kernel when the header is touched, which is, I guess, not what we
> want.

I agree with you, one big kernel header is hard to maintain, especially
by patches :-)

Thanks,


-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@xxxxxxxxxx

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