Re: [patch 06/16] Markers auto enable tracepoints (new API : trace_mark_tp())

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* Ingo Molnar (mingo@elte.hu) wrote:
> 
> * Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> 
> > > ... and in that sense i'd love to see lttng become a "super ftrace 
> > > plugin", and be merged upstream ASAP.
> > 
> > Hrm, a big part of LTTng is its optimized buffering mechanism, which 
> > has been more tested and is more flexible than the one currently 
> > found in ftrace (it has supported lockless NMI-safe tracing for over 
> > 2 years). It also separates the various tracing layers in separated 
> > modules, which helps not mixing the buffer management layer with the 
> > timestamping layer and with the memory backend layer.. I am opened 
> > to try to merge ftrace and lttng together, but I think it will be 
> > more than a simple "make lttng a ftrace plugin".
> 
> Sure, it will certainly be a fair bit of (interesting and useful!) 
> work.
> 
> But it's something we should do iteratively, instead of merging a 
> parallel framework. Steve's ring-buffer should be a fair step in the 
> right direction. Could we improve on that?
> 

I think it's a very good thing that both Steve and me went through the
effort of creating such buffering mechanism, because it created healthy
competition and we have been able to cross-check each other code (well,
I actually pointed out some bugs he had in his tracer code just because
I ran into the same issues).

The only thing is that ftrace needs are a subset of what LTTng needs and
provides. As Steve stated very clearly in the past weeks, he doesn't
care about exporting binary data in an organized self-described manner.
This is actually a key component of LTTng. Therefore, there seems to be
no will nor need to self-describe the information in the trace buffers
from Steve's point of view.

However, even if such self-description is not used by ftrace-type
tracers within the kernel, it could just be *there* so we can support
high-throughput streaming of organized (non-opaque) binary data when
needed. A ftrace tracer could then participate to this information flow
and make the data available for high-speed extraction. I think this
would be very beneficial to the LTTng use-cases and would not hurt
ftrace tracers at all.

> i see nothing in the feature list of LTTng that we wouldnt want to 
> have for ftrace, agreed?

Yes, the only thing is that LTTng might be doing a little bit more than
what ftrace needs, because it needs to export the information to
userspace.

> And we could do an ftrace tracer named 
> 'LTTng' which would interact with lttng userspace in the customary 
> way.

Or we could think of making ftrace be a LTTng information source, so it
would be able to export all its information to userspace through the
high-speed self-described binary trace buffers (channels) and also
manage to keep all of its current features. The way I see it, because
ftrace has simpler requirements due to the fact it does not export
binary data across the kernel boundary, ftrace buffering can be seen as
a subset of the LTTng requirements.

Besides, looking at LWN reviews of Steve's ring buffer implementation
"A casual perusal of the patch might well leave a reader confused; 2000
lines of relatively complex code to implement what is, in the end, just
a circular buffer. This circular buffer is not even suitable for use by
tracing frameworks yet; a separate "tracing" layer is to be added for
that."

I achieve all the core work of atomic-ops based buffering,
self-description of traces and all I said above with a design easier to
review in a few more lines, but distributed in smaller files :

   850 ltt-marker-control.c   (marker userspace control, event ID
                               management)
   179 ltt-relay.h
   701 ltt-relay-alloc.c      (buffer memory backend, vmap-less,
                               contiguous memory range emulated by software)
  1648 ltt-relay.c            (atomic buffer writer/reader
                               synchronization)
   780 ltt-tracer.h           (header definitions, prototypes, inlines)

Compared to : 
  2241 ring_buffer.c
   130 ring_buffer.h

So in the end, my argumentation is not based on a simple "I prefer my
code to someone else's code", but simply that I think it could be easier
to integrate the tracer with the fewer constraints into the tracer with
the more constraints (principally exporting data to userspace) than to
do the opposite.

And all ftrace could need that LTTng currently lacks (like in-kernel
binary-to-text converter) is currently on the LTTng roadmap.

Mathieu

> 
> 	Ingo

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68