Re: [PATCH 09/12] trace-cmd analyze: Add wake up latency timings

[John Keeping <john@metanate.com>]

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@goodmis.org> 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?