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
|