Я хотел бы выяснить, как отследить прерывания перепланирования.
Поскольку я заметил, что в моем приложении были некоторые невольные переключения контекста, а затем cat /proc/interrupts
показывает, что прерывания перепланирования произошли.
I подозревал, что это не имеет никакого отношения к моему приложению, поэтому я создал фиктивное приложение:
#include <cstdio>
#include <cstdlib>
#include <ctime>
#include <cstdint>
int main(int argc, char** argv) {
srand(time(nullptr));
int32_t i = 0;
while (i != rand()) i = rand() * -1;
printf("%d", i);
}
, которое в основном никогда не завершается.
Я скомпилировал его: /opt/rh/devtoolset-8/root/usr/bin/g++ -Wall dummy.cpp -o a -march=native -mtune=native -O0 -fno-omit-frame-pointer -std=c++17
Затем я запускаю taskset -c 5 ./a
, а затем cat /proc/interrupts
каждую секунду или около того. Я замечаю, что Rescheduling Interrupts
увеличивается на 1-2 каждую секунду, чего я не ожидаю. Local Timer Interrupt
также увеличивается на 1 каждую секунду, что ожидается. Я уже выделил ядро 5 в параметре загрузки.
Перепланирование прерываний другой машины увеличивается только на 1 каждые 30 минут или около того.
Следовательно, я ищу универсальный c способ отследить такого рода проблемы с прерываниями, чтобы в будущем я мог повторно применить ту же методологию для различных типов неожиданных прерываний.
Моя версия ядра:
# uname -a
Linux localhost 3.10.0-1062.1.2.el7.x86_64 #1 SMP Mon Sep 30 14:19:46 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Я также пытался taskset -c 4 perf record -e cycles:pp -C 5 -g --freq=12000
записать граф вызовов, но по какой-то причине граф вызовов функций ядра не был создан ... только пользовательское пространство.
Обновление 1: следуя предложению @ osgx, я запустил
taskset -c 4 perf record -e irq_vectors:reschedule_entry -c 1 --call-graph dwarf,4096 taskset -c 5 ./a
А затем perf report --call-graph
- 100.00% 100.00% vector=253 ▒
- 76.47% _start ▒
__libc_start_main ▒
- main ▒
- 64.71% rand ▒
- 58.82% __random ▒
- 29.41% 0xffffffffb298e06a ▒
0xffffffffb2991864 ▒
0xffffffffb22a4565 ◆
0xffffffffb222f675 ▒
- 0xffffffffb299042c ▒
- 23.53% 0xffffffffb22a41e5 ▒
0xffffffffb298f8da ▒
0xffffffffb2258ec2 ▒
- 5.88% 0xffffffffb298f8da
kernel-debuginfo
, kernel-debuginfo-common
, glibc-debuginfo
и glibc-debuginfo-common
были установлены и -fno-omit-frame-pointer
были указаны при компиляции. Не уверен, почему адреса отображаются в отчете вместо символов. Идея