Re: Kernel marker has no performance impact on ia64.

Peter Zijlstra
2008-06-13T11:01:38Z

On Thu, 2008-06-12 at 13:38 -0400, Frank Ch. Eigler wrote:
> Hi -
>
> On Thu, Jun 12, 2008 at 06:53:41PM +0200, Peter Zijlstra wrote:
> > [...]
> > > Think this through. How should systemtap (or another user-space
> > > separate-compiled tool like lttng) do this exactly?
> >
> > lttng has trace handlers to write data into some buffer, right?
> > The trace point need not be concerned with which data, nor into what
> > buffer.
>
> The "which data" is definitely a trace point concern. It communicates
> from the developer to users as to what values are likely to be of
> interest.

But that is tracer specific - I might write a scheduler tracer that
looks at the quality of scheduling decisions and thus wants to look at
the virtual timeline variables and the scheduling class of the tasks
involved.

That's a whole different context, but the trace points are the same. Are
you saying trace points are not to allow me to do that?

> > > (a) rely on debugging information? Even assuming we could get proper
> > > anchors (PC addresses or unambiguous type names) to start
> > > searching dwarf data, we lose a key attractions of markers: that
> > > it can robustly transfer data *without* dwarf data kept around.
> >
> > Perhaps you can ship a reduced set of dwarf info [...]
>
> "I" don't ship or generate dwarf data. Distributors do.

That's ignoring the point - 'someone' could generate reduced debug info
to allow you to easily get what you want.

> > > (b) rely on hand-written C code (prototypes, pointer derefrencing
> > > wrappers) distributed with systemtap? Not only would this be a
> > > brittle maintenance pain in the form of cude duplication, but then
> > > errors in it couldn't even be detected until the final C
> > > compilation stage. That would make a lousy user experience.
> >
> > Not really sure what you mean here - I throught compile time errors
> > were the goal?!
>
> For us, it's too late. In systemtap, we try to give people useful
> information when they make mistakes. For probes of whatever sort, we
> want to know the available data types and names, while just starting
> to process their script, so that we can check types and suggest
> alternatives. C code compilation is quite some way removed and is
> supposed to be a systemtap internal implementation detail.

Sounds like you have an incomplete Native-Interface system then. You
should be able to match a native function description back to your
script language.

> > > (c) have systemtap try to parse the mhiramat-proposed "(struct
> > > task_struct * next, struct task_struct * prev)" format strings?
> > > Then we're asking systemtap to parse potentially general C type
> > > expressions, find the kernel headers that declare the types?
> > > Parse available subfields? That seems too much to ask for.
> >
> > tcc and sourcefs sound like way fun ;-)
>
> Really...

Yeah, wouldn't it be cool if the kernel came with an embedded compiler
and a filesystem that included its exact source code? Together with the
entry instrumentation site and dynamic jump patches you can do really
weird stuff... /me dreams on :-)

> > > (d) or another way?
> >
> > Get your own tracer in kernel - that provides exactly what stap needs?
>
> You are missing that (a) this is the point of markers - to allow the
> the gajillion tracers a single place per event to hook through, and
> (b) we would like to leave to subsystem developers and/or end-users as
> to what data should be available. We don't want to get into the
> middle of it.

I think a) and b) contradict each other, you cannot cater for all
tracers and limit the data they can use.