当一个进程唤醒同一内核上的另一个进程时，将使用两个PID生成sched:sched_wakeup事件.这对于查找流程之间的关系非常有用.
When a process wakes another process on the same core, a sched:sched_wakeup event is generated with both PIDs. This is great for finding relationships between processes.
当一个进程在另一个内核上唤醒另一个进程时，第二个内核会在任何一个不幸捕获IPI的进程上生成irq_vectors:reschedule_entry事件，然后是该受害进程的sched:sched_wakeup事件.
When a process wakes another process on a different core, the second core generates an irq_vectors:reschedule_entry event on whichever process is unlucky enough to catch the IPI, followed by a sched:sched_wakeup event from that victim process.
我找不到在唤醒的第一个内核上的原始进程.发送重新安排IPI的地址.
What I can't find is the original process on the first core that does the waking. The one that sends the reschedule IPI.
是否存在与发送重新安排中断有关的任何事件，或者与进程中的其他任何事件有关?
Is there any event associated with sending a reschedule interrupt, or with anything else in the process?
(如果不明显，我使用的是性能记录"，而不是性能统计")
(In case it isn't apparent, I'm using "perf record", not "perf stat")
推荐答案布伦丹·格雷格(Brendan Gregg)在他的《 BPF Performance Tools》一书中说没有用于重新安排IPI中断功能的主要性能事件或跟踪点 smp_send_reschedule()
Brendan Gregg in his book "BPF Performance Tools" says that there is no perf event or tracepoint for main rescheduling IPI interrupt function smp_send_reschedule()
有一个特殊的SMP调用smp_send_reschedule()未涵盖，可通过 native_smp_send_reschedule().我希望将来的内核版本支持SMP调用跟踪点，以简化对这些调用的跟踪.
There is a special SMP call not covered by those functions, smp_send_reschedule(), which is traced via native_smp_send_reschedule(). I hope that a future kernel version supports SMP call tracepoints to simplify tracing of these calls.
2013年，有人提出了一个修补程序，用于在ARM平台上向IPI添加跟踪: lore.kernel/patchwork/patch/413825 ARM:跟踪:为处理器间中断添加跟踪点
In 2013 there was a patch proposed to add tracing to IPI on ARM platform: lore.kernel/patchwork/patch/413825 ARM: trace: Add tracepoint for the Inter Processor Interrupt
smp_send_reschedule，包括内核/sched/core.c 函数resched_curr，wake_up_idle_cpu，kick_process，ttwu_queue_remote，wake_up_if_idle，但是它们没有IPI代码路径的跟踪.您可以尝试将一些perf探针添加到某些功能中.
smp_send_reschedule is called from several places including kernel/sched/core.c functions resched_curr, wake_up_idle_cpu, kick_process, ttwu_queue_remote, wake_up_if_idle, but they have no tracing for IPI code path. You may try to add some perf probe to some functions.
更多推荐
发送重新安排中断的性能事件?
发布评论