Adding latency tracking to trace-cmd

[Steven Rostedt <rostedt@goodmis.org>]

Hi Viktor,

While doing some tests to trace-cmd, I found that the trace-cmd record was
broken for latency tracers, and has been for some time. That's probably
because nobody has been using it for such.

That is, trace-cmd record is mostly used for "flyrecord" which is the
constant recording of tracing. But if the user records one of the latency
tracers (preemptirqsoff, wakeup_rt, etc), then it switches to "latency"
mode and only takes a snapshot at the end of the recording. This is what I
found to be broken, because it reset the tracing before taking the
snapshot and lost whatever it was recording. Nobody seemed to complain
about it, so I guess nobody cared.

The fix is simple, and I was about to do so, but then I thought about your
latency-collector tool, and thought that should be exactly what trace-cmd
should do for such tracers. That is, instead of just taking a snapshot of
the latency at the end of the recording (which it was suppose to do now),
it should act like your latency-collector tool, and take snapshots
every time there's a new latency.

My question to you is, would you like to work on adding that feature to
trace-cmd?

  git://git.kernel.org/pub/scm/utils/trace-cmd/trace-cmd.git

(which requires the libtracefs and libtracevent libraries).

I'm thinking if someone were to do:

 trace-cmd record -p wakeup_rt 

It would then act just like the latency-collector and record every new
instance of a latency into the trace.dat file, where:

 trace-cmd report

would then nicely format that data for the user.

Thoughts?

-- Steve