[ltt-dev] [RFC] New UST 2.0 Tracepoint Event API

[Mathieu Desnoyers]

* Nathan Scott (nathans at debian.org) wrote:
> Hi Mathieu,
> 
> On 28 July 2011 05:06, Mathieu Desnoyers <mathieu.desnoyers at efficios.com>wrote:
> 
> > Hi all,
> >
> > I'd like to get feedback on the new UST 2.0 tracepoint event API.
> > The code still needs to be debugged (it does not compile yet), but the
> > basic structure of the API is in place, and I'd like to get feedback on
> > this.
> > ...
> > Note: the print formatting information is actually metadata exported for
> > the trace viewer. It does not add information to each event in the
> > trace.
> 
> ...
> 
> The tracepoint.h header contains a lengthy comment describing the
> > TRACEPOINT_EVENT() API, along with a usage example:
> >
> > http://git.lttng.org/?p=ust.git;a=blob;f=include/ust/tracepoint.h
> >
> > The macros describing the types available within the TP_FIELDS macro are
> > described at the beginning of:
> >
> >
> > http://git.lttng.org/?p=ust.git;a=blob;f=include/ust/lttng-tracepoint-event.h
> >
> >
> This link appears to be broken...?

My bad, I should not have removed the reference to the lttng-ust-2.0
branch. The correct links are:

http://git.lttng.org/?p=ust.git;a=blob;f=include/ust/tracepoint.h;hb=refs/heads/lttng-ust-2.0

http://git.lttng.org/?p=ust.git;a=blob;f=include/ust/lttng-tracepoint-event.h;hb=refs/heads/lttng-ust-2.0


> The examples in the email didn't seem
> to
> mention floating point trace info - is that catered for?  Its not so useful
> in the
> kernel, but for userspace tracing its much more likely to be needed I guess.
> 
> Thoughts ?

Very good point. CTF already has the support for it, but I need to add
it to TRACEPOINT_EVENT. Will do. I plan to add support for e.g.:

    ctf_float(double, field_name, argument)

Makes sense ?

> >
> 
> In addition to the type information that the format string provides,
> it could also be very useful for a consumer tool to be able to tell
> the units of the trace data - bytes, kilobytes, milliseconds,
> nanoseconds, etc.  Not sure I can think of a neat way to add that into
> the API though - perhaps extending the format string with optional
> type decorator?  Might be a bit counter-intuitive/ugly.

The way we could see doing this with the current infrastructure is to
end the field labels with units, e.g.:

 TRACEPOINT_EVENT(< [com_company_]project_[component_]_event >,
     TP_PROTO(struct timespec ts),
     TP_ARGS(ts),
     TP_FIELDS(
           ctf_integer(typeof(ts.tv_sec), time_seconds, ts.tv_sec)
           ctf_integer(typeof(ts.tv_nsec), time_nanoseconds, tv.tv_nsec)
     )
 )

So far, I am not planning to support "format strings" within the events:
the idea is that the field names should be sufficient to identifiy the
associated data, and it leaves more room for formatting to the trace
analysis tools.

Thoughts ?

> 
> Other random thoughts that occur - I've seen some tracing systems that
> have a "trace caliper" concept, where the start (say, of a
> transaction) and the end can be linked ... would this be useful as an
> explicit part of the API, or is it something that could/should be
> built at a higher level?  These other tracers also tend to do what
> they call "end-to-end" tracing, where a trace hierarchy can be built
> (using the caliper start/end concepts) - not sure how that would be
> added to the API, but just thought I'd throw it out there for your
> consideration anyway.

I'm thinking of adding this as a higher-level: e.g. a function tracer
could choose to suffix the function names with _entry and _return
suffix, and the trace analysis tool would be aware that those match. I
don't see much benefit in forcing these pairs at the instrumentation
level though, as this can be done by the instrumented system. Also, we
need to take nesting and preemption into account when we present these
pairs, so I kind of doubt we can reliably present all "begin/end" pairs
with just a simple pre-defined suffix: the trace analyser will need to
be aware of the context (e.g. get the thread ID context with each event
to know to which thread the begin/end pairs belong, and also keep a
nesting counter of begin/end pairs to match the pairs together).

But maybe I am missing something here ?

I was also wondering if putting a "loglevel" information (could be
optional) into the TRACEPOINT_EVENT declaration would be useful ? This
could define log levels such as debug, info, warning, and error.

Thanks,

Mathieu

> 
> HTH.
> 
> cheers.
> 
> --
> Nathan

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com