Re: [patch 00/37] Linux Kernel Markers instrumentation for sched-devel.git

[Masami Hiramatsu <mhiramat@redhat.com>]

Peter Zijlstra wrote:
> On Mon, 2008-04-28 at 11:36 -0700, Andrew Morton wrote:
>> On Sat, 26 Apr 2008 21:38:54 +0200 Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>>> lets hide the ugly bits.
>> It hides the cosmetically-ugly bits, but not the deeply ugly: each of these
>> trace points is an extension to the kernel->userspace API, with all that
>> this implies.
> 
> Agreed, and I'm rather concerned about that as well. OTOH its very
> unlikely we'll ever have a Linux that will not have a context switch, or
> task wakeup operation.
> 
> So tracing these and things like syscall seem safe enough to do -
> although I wish it wouldn't look so ugly. 

What would you think about the basic-hardware events like
interruptions, and exceptions?:-)

> As for some of these other trace points in this set, dubious.
> 
> We can of course clearly state that any marker is free of API
> constraints and users will have to cope with them changing. But I'm not
> sure that's a realistic position.


BTW, I also have a question about the maintenance policy of markers.
Who will pay a cost for updating (maintaining) those trace points
according to changing logic of the kernel?

I think that each developer who modifies the kernel has to fix
trace points just for removing compile-errors. They can (but don't need to)
leave, update or remove the trace points to fit their changes, because they
knows their changes precisely, but they don't know why the trace points are
there and what information is required.
So, trace points should be basically maintained by trace point maintainers
who know all about the trace points.
is that right?

Thanks,

Best regards,

-- 
Masami Hiramatsu

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

e-mail: mhiramat@redhat.com