[lttng-dev] introduction & usage of LTTNG in machinekit

[Michel Dagenais]

> >> - is there a complete example out-of-tree kernel module instrumented for LTTng? 
> > A few people in my group have done so. I will check on Monday to get sample
> > code for you.
> on re-reading, I am almost there, but I'd appreciate an example anyway

Julien has sent an example. Now that you will be getting real-time traces, someone in my group, Mathieu Côté, is working specifically on views to help diagnose real-time problems. He will be in a position to help you and can even improve the current TraceCompass views if you have specific "real-time programming" "use cases" not currently well covered.  

> >> - much of the machinekit RT code (HAL library and components) can be compiled
> >> as userland shared objects (Posix, RT-PREEMPP, Xenomai threads) or kernel
> >> modules (RTAI, and the deprecated Xenomai kernel API), sitting ontop of an
> >> abstracted realtime API ("RTAPI"). Ideally the tracepoints would work
> >> unchanged except for the different context.

I checked with Mathieu Desnoyers about LTTng and Xenomai. He has not looked at it. Karim Yaghmour developed the original LTT while working in my group and adapted it to Xenomai. Later on, I believe that someone else within Xenomai switched Xenomai from LTT to LTTng but this has not necessarily been maintained. LTTng is built to work even in NMI conext and thus relies on very few kernel services. It mostly uses RCU critical sections: disabling preemption between read lock and read unlock, and calling synchronize_rcu.

> > MariaDB and others can target different tracers (LTTng, DTrace, none)...
> > Again, I will try to get you good sample code early next week.

QEMU is another example of project which interfaces to LTTng but can have other or no tracer as well.

> semi-related because I was bitten by it: the Xenomai configs referenced here:
> http://www.xenomai.org/pipermail/xenomai/2013-January/027272.html turn
> CONFIG_FTRACE off, citing performance reasons. I think we'll turn it back on
> in our kernels, cant be that much extra overhead.

If the option is enabled but tracing is not active, there are simply a few bytes of nops added at the beginning of each function. The processor pipeline is indeed extremely efficient at skipping those and the impact is barely measurable.