On 08/10/22 15:34, Steven Rostedt wrote:
> On Fri, 7 Oct 2022 16:45:32 +0100
> Valentin Schneider wrote:
>> }
>>
>> +static inline void irq_work_raise(void)
>> +{
>> +if (arch_irq_work_has_interrupt())
>> +trace_ipi_send_cpu(_RET_IP_, smp_processor_id());
>
> To save on the bra
+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
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
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
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
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
