Thread (16 messages) 16 messages, 5 authors, 2022-10-11

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

From: Steven Rostedt <rostedt@goodmis.org>
Date: 2022-10-08 19:40:41
Also in: linux-alpha, linux-arm-kernel, linux-mips, linux-riscv, linux-s390, linux-sh, lkml, loongarch, sparclinux

On Fri, 7 Oct 2022 17:01:33 -0300
Marcelo Tosatti [off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help