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

Christopher Kenna cjk at cs.unc.edu
Fri Feb 17 00:40:05 CET 2012


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?

Thanks,
Chris


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
>
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
>




More information about the litmus-dev mailing list