[LITMUS^RT] RFC: kernel-style events for Litmus^RT

[Andrea Bastoni]

On 02/17/2012 12:40 AM, Christopher Kenna wrote:
> Hi Andrea,
> 
> Thanks for doing this. The tracepoints code is interesting. I have a general
> question about it, if you or anyone else knows the answer.
> 
> I was wondering how TRACE_EVENT actually declares the struct that you pass
> it, as well as do the assignment. The TRACE_EVENT macro is declared (AFAIK)
> as:
> 
> TRACE_EVENT(name, proto, args, struct, assign, print) \ DECLARE_TRACE(name,
> PARAMS(proto), PARAMS(args))
> 
> This makes it seem like the arguments struct, assign, and print to 
> TRACE_EVENT are not used, but I know that can't be. I checked what the macros
> for TP_STRUCT__entry and others do, but they're basically just repetition of
> their arguments without modification. So how does declaring the struct and
> setting up the code to do the assignment work?

Hi Chris,

I'm also not sure I fully get all the cpp obscurity behind TRACE_EVENT macro. :)

To try to make the long story short, the one above is not the only define of
TRACE_EVENT. TRACE_EVENT is defined multiple times, and appropriately undefined,
to obtain different behaviors with the same parameters.

It's not a case that at the beginning of [include/trace/events/litmus.h] we
define TRACE_HEADER_MULTI_READ (to allow the header file to be read multiple
time), and at the end of the same file we include define_trace.h, which includes
the including file again ("#include TRACE_INCLUDE(TRACE_INCLUDE_FILE)").

The final macro unrolling is in [include/trace/ftrace.h].

Actually Steven Rostedt explained this tricks way better than me in an LWN article:

http://lwn.net/Articles/383362/

(These are the previous two:

http://lwn.net/Articles/381064/
http://lwn.net/Articles/379903/

)

Thanks,

- Andrea

> On Sat, Feb 11, 2012 at 4:17 PM, Andrea Bastoni <bastoni at cs.unc.edu> wrote:
>> Hi all,
>> 
>> I've managed to expand and polish a bit a patch that I've had around for a 
>> while. It basically enables the same sched_trace_XXX() functions that we 
>> currently use to trace scheduling events, but it does so using
>> kernel-style events (/sys/kernel/debug/tracing/ etc.).
>> 
>> So, why another tracing infrastructure: - Litmus tracepoints can be
>> recorded and analyzed together (single time reference) with all other
>> kernel tracing events (e.g., sched:sched_switch, etc.). It's easier to
>> correlate the effects of kernel events on litmus tasks.
>> 
>> - It enables a quick way to visualize and process schedule traces using
>> trace-cmd utility and kernelshark visualizer. Kernelshark lacks
>> unit-trace's schedule-correctness checks, but it enables a fast view of
>> schedule traces and it has several filtering options (for all kernel
>> events, not only Litmus').
>> 
>> Attached (I hope the ML won't filter images ;)) you can find the
>> visualization of a simple set of rtspin tasks. Particularly, getting the
>> trace of a single task is straightforward using trace-cmd:
>> 
>> # trace-cmd record -e sched:sched_switch -e litmus:* ./rtspin -p 0 50 100
>> 2
>> 
>> and to visualize it:
>> 
>> # kernelshark trace.dat
>> 
>> trace-cmd can be fetch here:
>> 
>> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
>> 
>> (kernelshark it's just the "make gui" of trace-cmd; trace-cmd and
>> kernelshark have a lot more features than simple filtering and
>> visualization; hopefully it should be a good help for debugging.)
>> 
>> The patch is on "wip-tracepoints" on main repository and jupiter.
>> 
>> Info on trace-cmd, kernelshark, and ftrace are available here:
>> 
>> http://lwn.net/Articles/341902/ http://lwn.net/Articles/425583/ 
>> http://rostedt.homelinux.com/kernelshark/ http://lwn.net/Articles/365835/ 
>> http://lwn.net/Articles/366796/
>> 
>> Thanks, - Andrea