On Fri, Mar 25, 2022 at 04:31:48PM -0400, Steven Rostedt wrote:
> On Fri, 25 Mar 2022 16:13:33 -0400
> Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> > I'll fix it in v2.
>
> BTW, I plan on rewriting a lot of this to move it into libtracecmd. That
> way other tools can easily extract data from it.
>
> For example, instead of hard coding "page faults" and "wake ups" I plan on
> adding a way to register events to trigger on. Something like:
>
> tracecmd_analyze_register_event_timing(handle, name, start_event,
> start_field, start_record, end_event, end_field,
> end_record);
>
> Where "start_record" and "end_record" is if the field is a task to record.
>
> enum {
> TRACECMD_ANALYZE_FL_NONE,
> TRACECMD_ANALYZE_FL_PID,
> TRACECMD_ANALYZE_FL_PID_CPU,
> };
>
> Thus, we could have:
>
> tracecmd_analyze_register_event_timing(handle,
> "Wakeup", sched_waking,
> pid_field, TRACECMD_ANALYZE_FL_PID,
> sched_switch, next_pid,
> TRACECMD_ANALYZE_FL_PID_CPU);
>
> Or something like the above, that will end up turning into the
> process_wakeup() function (and properly record the waking pid globally).
This sounds really neat.
I started having a look at whether it's possible to add an overview of
interrupts from irq:irq_handler_entry & irq:irq_handler_exit and I guess
that would fit in TRACECMD_ANALYZE_FL_NONE above, but it would be good
to have per-cpu stats for irqs as well so does that mean an additional
record type is needed?
