当一个进程唤醒同一个内核上的另一个进程时，会使用两个 PID 生成一个 sched:sched_wakeup 事件。这对于查找进程之间的关系非常有用。
当一个进程唤醒另一个内核上的另一个进程时，第二个内核会在任何一个不幸捕获 IPI 的进程上生成 irq_vectors:reschedule_entry 事件，然后是来自该受害进程的 sched:sched_wakeup 事件。
我找不到的是第一个核心上唤醒的原始过程。发送重新安排 IPI 的那个。
是否有与发送重新安排中断相关的任何事件，或与过程中的任何其他事件相关联？
（如果不明显，我使用的是“perf record”，而不是“perf stat”）
Brendan Gregg 在他的《BPF 性能工具》一书中说，主要重新调度 IPI 中断函数没有性能事件或跟踪点 smp_send_reschedule()
这些函数没有涵盖一个特殊的 SMP 调用，即 smp_send_reschedule()，它通过native_smp_send_reschedule()进行跟踪。我希望未来的内核版本支持 SMP 调用跟踪点以简化对这些调用的跟踪。
2013 年，有人提议在 ARM 平台上为 IPI 添加跟踪：https ://lore.kernel.org/patchwork/patch/413825 ARM：跟踪：为处理器间中断添加跟踪点
smp_send_reschedule 是从几个地方调用的，包括kernel/sched/core.c函数resched_curr, wake_up_idle_cpu, kick_process, ttwu_queue_remote, wake_up_if_idle，但它们没有跟踪 IPI 代码路径。您可以尝试为某些功能添加一些性能探针。