Re: [RFC PATCH 4/5] irq_work: Trace calls to arch_irq_work_raise()

[Steven Rostedt]

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 branch, let's make the above:

if (trace_ipi_send_cpu_enabled() && arch_irq_work_has_interrupt())

As the "trace_*_enabled()" is a static branch that will make it a nop
when the tracepoint is not enabled.

-- Steve


> +
> + arch_irq_work_raise();
> +}
> +
>  /* Enqueue on current CPU, work must already be claimed and preempt disabled 
> */

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

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

[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 on a
> > cpumask via trace-cmd.  
> 
> https://man7.org/linux/man-pages/man1/trace-cmd-set.1.html
> 
>-f filter
>Specify a filter for the previous event. This must come after
>a -e. This will filter what events get recorded based on the
>content of the event. Filtering is passed to the kernel
>directly so what filtering is allowed may depend on what
>version of the kernel you have. Basically, it will let you
>use C notation to check if an event should be processed or
>not.
> 
>==, >=, <=, >, <, &, |, && and ||
> 
>The above are usually safe to use to compare fields.

We could always add an "isset(x)" filter ;-)

-- Steve

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc