On Tue, Feb 6, 2024 at 12:05 AM Valentin Schneider <vschn...@redhat.com> wrote: > > On 05/02/24 14:39, Mark Rutland wrote: > > [adding Valentin] > > > > Thanks! > > > On Mon, Feb 05, 2024 at 08:06:09AM -0500, Steven Rostedt wrote: > >> On Mon, 5 Feb 2024 10:28:57 +0000 > >> Mark Rutland <mark.rutl...@arm.com> wrote: > >> > >> > > I try to write below: > >> > > echo 'target_cpus == 11 && reason == "Function call interrupts"' > > >> > > events/ipi/ipi_raise/filter > >> > > >> > The '=' checks if the target_cpus bitmap *only* contains CPU 11. If the > >> > cpumask > >> > contains other CPUs, the filter will skip the call. > >> > > >> > I believe you can use '&' to check whether a cpumask contains a CPU, e.g. > >> > > >> > 'target_cpus & 11' > >> > >> 11 == 0xb = b1011 > >> > >> So the above would only be true for CPUs 0,1 and 3 ;-) > > > > Sorry, I misunderstood the scalar logic and thought that we treated: > > > > '$mask $OP $scalar', e.g. 'target_cpus & 11' > > > > .. as a special case meaning a cpumask with that scalar bit set, i.e. > > > > '$mask $OP CPUS{$scalar}', e.g. 'target_cpus & CPUS{11}' > > > > .. but evidently I was wrong. > > > >> I think you meant: 'target_cpus & 0x800' > >> > >> I tried "1 << 11' but it appears to not allow shifts. I wonder if we > >> should add that? > > > > Hmm... shouldn't we make 'CPUS{11}' work for that? > > > > It /should/ already be the case, the user input with the curly braces is > parsed as a cpulist. So CPUS{11} really does mean CPU11, not a hex value to > be interpreted as a cpumask. > > However... > > > From a quick test (below), that doesn't seem to work, though I think it > > probably should? > > Have I completely misunderstood how this is supposed to work, or is that a > > bug? > > > > The CPUS{} thingie only works with an event field that is either declared as a > cpumask (__cpumask) or a scalar. That's not the case for ipi_raise, the > target_cpus event field is saved as a "raw" bitmask. > > There /should/ have been a warning about the event filter though, but I > think it's not happening because I'm allowing more than just FILTER_CPUMASK > in parse_pred() to make it work for scalars. I'll go poke around some more. > > Generally for this sort of IPI investigation I'd recommend using the newer > trace_ipi_send_cpu() and trace_ipi_send_cpumask() (for which CPUS{} > filtering works). > If it's only the function call interrupts you're interesting in, have a > look at trace_csd_queue_cpu().
This should be supported by newer version kernels like v6.5, but I am using v6.1 and this trace event has not been supported yet... so ipi is more suitable for me. ipi_entry and ipi_exit is ok, but seems the filter doesn't support a specific cpu, maybe we need to add this? > > > Mark. >