В настоящее время я изучаю проблему производительности платформы NXP для приложения пересылки DPDK. Ниже приведена информация о настройке:
При работе с трафиком я наблюдаю, что ядро 7 имеет некоторую задачу в контексте обработки IPI, так что 100% пропускная способность ЦП не используется приложением DPDK. Ниже приведен снимок хвоста /proc/interrupts.
root @ localhost: / usr / local / dpdk / dpaa2 # tail / proc / interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
394: 0 0 0 0 0 0 0 0 ITS-fMSI 240024 Edge vfio-irq[394](dpio.8)
395: 0 0 0 0 0 0 0 0 ITS-fMSI 240025 Edge vfio-irq[395](dpio.9)
IPI0: 5912 88 90 88 87 86 88 202 Rescheduling interrupts
IPI1: 64 3203 3203 3203 3203 3203 3203 3139 Function call interrupts
IPI2: 0 0 0 0 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 0 0 0 0 CPU stop (for crash dump) interrupts
IPI4: 0 0 0 0 0 0 0 0 Timer broadcast interrupts
IPI5: 48795343 91 146481 146479 146481 146479 32 48816043 IRQ work interrupts
IPI6: 0 0 0 0 0 0 0 0 CPU wake-up interrupts
Теперь я изучаю, какая служба отвечает за генерацию этих прерываний IPI. В моем случае IPI5 постоянно увеличивается. Может кто-нибудь помочь мне найти решение. Есть ли какая-нибудь утилита Linux для анализа / отслеживания этих прерываний?
Заранее спасибо.
Сунил Кумар
Вы должны быть в состоянии отследить большинство причин удаленного пробуждения через perf sched
. См.
Как только вы обнаружили с помощью первого, что вы думаете, запускает IPI, вы можете использовать более подробные примеры, чтобы отследить, что именно происходит.
Если ничего из общего (более простого в использовании) не работает, попробуйте отследить
IPI - Межпроцессорное прерывание, генерируется одним процессором для отправки задачи другому процессору.
В вашем случае кажется, что CPU-7 получает слишком много IP из-за сетевого трафика. Обычно сетевые прерывания отправляются на CPU-0. Поскольку приложение, обрабатывающее пакеты, выполняется на CPU-7, CPU-0 передает пакет через IPI.
Этого можно избежать, запустив приложение на CPU-0 или закрепив сетевые прерывания на CPU-7.