> Hi Peter and Mathieu,
>
> Thank you for your comments.
>
> Mathieu Desnoyers wrote:
> > * Peter Zijlstra (
peterz@infradead.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.
>
> Sure, I think we should review each point carefully
> and should make clear rules what is acceptable or not and why.
>
> >>
> >> 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).
>
> 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)?
>
