Will smp_call_function_single(cpu, ...) broadcast IPI to all other cpus?
Marc Zyngier
maz at kernel.org
Thu Jun 27 03:38:58 PDT 2024
On Thu, 27 Jun 2024 10:26:05 +0100,
richard clark <richard.xnu.clark at gmail.com> wrote:
>
> Hi,
> There's a smp_call_function_single(10, ipi_cb_func, &data_info, 1)
> called by the init function of my kmod, then I ipi traces this
> smp_call_function_single(...) with below cmdline:
>
> # echo 0 > /sys/kernel/debug/tracing/tracing_on; echo >
> /sys/kernel/debug/tracing/trace; echo 'reason=="Function call
> interrupts"' > /sys/kernel/debug/tracing/events/ipi/filter; echo 1 >
> /sys/kernel/debug/tracing/events/ipi/ipi_raise/enable; echo 1 >
> /sys/kernel/debug/tracing/events/ipi/ipi_entry/enable; echo 1 >
> /sys/kernel/debug/tracing/tracing_on; taskset -c 0 insmod
> /kmods/ipi_test.ko; echo 0 > /sys/kernel/debug/tracing/tracing_on;
> echo 0 > /sys/kernel/debug/tracing/events/ipi/ipi_raise/enable; echo 0
> > /sys/kernel/debug/tracing/events/ipi/ipi_entry/enable; echo >
> /sys/kernel/debug/tracing/events/ipi/filter; cat
> /sys/kernel/debug/tracing/trace
>
> The trace output as below:
>
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 28/28 #P:12
> #
> # _-------=> irqs-off/BH-disabled
> # / _------=> need-resched
> # | / _-----=> need-resched-lazy
> # || / _----=> hardirq/softirq
> # ||| / _---=> preempt-depth
> # |||| / _--=> preempt-lazy-depth
> # ||||| / _-=> migrate-disable
> # |||||| / delay
> # TASK-PID CPU# ||||||| TIMESTAMP FUNCTION
> # | | | ||||||| | |
>
> <idle>-0 [009] dn.h2.. 555.400822: ipi_raise:
> target_mask=00000000,00000002 (Function call interrupts)
> <idle>-0 [001] d..h1.. 555.400832: ipi_entry:
> (Function call interrupts)
> insmod-1644 [000] ....1.. 555.401628: ipi_raise:
> target_mask=00000000,00000ffe (Function call interrupts)
> <idle>-0 [001] d..h1.. 555.401630: ipi_entry:
> (Function call interrupts)
> <idle>-0 [009] d..h1.. 555.401631: ipi_entry:
> (Function call interrupts)
> <idle>-0 [011] d..h1.. 555.401633: ipi_entry:
> (Function call interrupts)
> <idle>-0 [003] d..h1.. 555.401633: ipi_entry:
> (Function call interrupts)
> <idle>-0 [008] d..h1.. 555.401633: ipi_entry:
> (Function call interrupts)
> <idle>-0 [002] d..h1.. 555.401634: ipi_entry:
> (Function call interrupts)
> <idle>-0 [010] d..h1.. 555.401634: ipi_entry:
> (Function call interrupts)
> <idle>-0 [004] d..h1.. 555.401635: ipi_entry:
> (Function call interrupts)
> <idle>-0 [005] d..h1.. 555.401635: ipi_entry:
> (Function call interrupts)
> <idle>-0 [006] d..h1.. 555.401635: ipi_entry:
> (Function call interrupts)
> <idle>-0 [007] d..h1.. 555.401635: ipi_entry:
> (Function call interrupts)
> insmod-1644 [000] ....1.. 555.401643: ipi_raise:
> target_mask=00000000,00000ffe (Function call interrupts)
> <idle>-0 [001] d..h1.. 555.401644: ipi_entry:
> (Function call interrupts)
> <idle>-0 [002] d..h1.. 555.401645: ipi_entry:
> (Function call interrupts)
> <idle>-0 [003] d..h1.. 555.401645: ipi_entry:
> (Function call interrupts)
> <idle>-0 [004] d..h1.. 555.401645: ipi_entry:
> (Function call interrupts)
> <idle>-0 [006] d..h1.. 555.401645: ipi_entry:
> (Function call interrupts)
> <idle>-0 [005] d..h1.. 555.401645: ipi_entry:
> (Function call interrupts)
> <idle>-0 [007] d..h1.. 555.401645: ipi_entry:
> (Function call interrupts)
> <idle>-0 [008] d..h1.. 555.401645: ipi_entry:
> (Function call interrupts)
> <idle>-0 [009] d..h1.. 555.401645: ipi_entry:
> (Function call interrupts)
> <idle>-0 [010] d..h1.. 555.401645: ipi_entry:
> (Function call interrupts)
> <idle>-0 [011] d..h1.. 555.401646: ipi_entry:
> (Function call interrupts)
> insmod-1644 [000] ....1.. 555.401908: ipi_raise:
> target_mask=00000000,00000400 (Function call interrupts)
> <idle>-0 [010] d..h1.. 555.401911: ipi_entry:
> (Function call interrupts)
>
> I am curious why there're two IPI broadcasts to all the other
> cpus(1-11) before the real smp_call_function_single(10) trace
> event(the last two lines of the above trace output), any comments
> about that?
You may want to enable stack trace recording and find out for yourself
where these ipi_raise() calls are coming from.
M.
--
Without deviation from the norm, progress is not possible.
More information about the linux-arm-kernel
mailing list