Re: [RFC PATCH 0/5] Generic IPI sending tracepoint

2022-10-11 Thread Steven Rostedt
On Tue, 11 Oct 2022 17:40:26 +0100 Valentin Schneider wrote: > > You could keep the tracepoint as a mask, and then make it pretty, like > > cpus=3-5,8 > > in user-space. For example with a trace-cmd/perf loadable plugin, > > libtracefs helper. > > > > That's a nice idea, the one downside I s

Re: [RFC PATCH 0/5] Generic IPI sending tracepoint

2022-10-11 Thread Steven Rostedt
On Tue, 11 Oct 2022 17:17:04 +0100 Valentin Schneider wrote: > tep_get_field_val() just yields an unsigned long long of value 0x200018, > which AFAICT is just the [length, offset] thing associated with dynamic > arrays. Not really usable, and I don't see anything exported in the lib to > extract

Re: [RFC PATCH 0/5] Generic IPI sending tracepoint

2022-10-11 Thread Valentin Schneider
On 11/10/22 18:22, Daniel Bristot de Oliveira wrote: > On 10/11/22 18:17, Valentin Schneider wrote: >> Thinking out loud, it makes way more sense to record a cpumask in the >> tracepoint, but perhaps we could have a postprocessing step to transform >> those into N events each targeting a single CPU

Re: [RFC PATCH 0/5] Generic IPI sending tracepoint

2022-10-11 Thread Daniel Bristot de Oliveira
On 10/11/22 18:17, Valentin Schneider wrote: > Thinking out loud, it makes way more sense to record a cpumask in the > tracepoint, but perhaps we could have a postprocessing step to transform > those into N events each targeting a single CPU? My approach on the tracers/rtla is to make the simple t

Re: [RFC PATCH 0/5] Generic IPI sending tracepoint

2022-10-11 Thread Valentin Schneider
+Cc Douglas On 07/10/22 17:01, Marcelo Tosatti wrote: > Hi Valentin, > > On Fri, Oct 07, 2022 at 04:41:40PM +0100, Valentin Schneider wrote: >> Background >> == >> >> As for the targeted CPUs, the existing tracepoint does export them, albeit in >> cpumask form, which is quite inconvenient

Re: [RFC PATCH 0/5] Generic IPI sending tracepoint

2022-10-08 Thread Steven Rostedt
On Fri, 7 Oct 2022 17:01:33 -0300 Marcelo Tosatti wrote: > > As for the targeted CPUs, the existing tracepoint does export them, albeit > > in > > cpumask form, which is quite inconvenient from a tooling perspective. For > > instance, as far as I'm aware, it's not possible to do event filtering

Re: [RFC PATCH 0/5] Generic IPI sending tracepoint

2022-10-07 Thread Marcelo Tosatti
Hi Valentin, On Fri, Oct 07, 2022 at 04:41:40PM +0100, Valentin Schneider wrote: > Background > == > > Detecting IPI *reception* is relatively easy, e.g. using > trace_irq_handler_{entry,exit} or even just function-trace > flush_smp_call_function_queue() for SMP calls. > > Figuring out