линукс; Как отлаживать источник spin_lock

тл;др

В исходном файле ядра `net/packet/af_packet.c есть различные спин-блокировки и мьютексы. Я могу прочитать исходный код и посмотреть, какие функции используют блокировки и в каком порядке они вызываются, но я не могу сказать, когда-либо вращаться или как долго, просто от чтения кода. Мне нужно видеть, что на самом деле происходит во время выполнения.

Как я могу отследить источник спин-блокировок для одного приложения?

Фон

Я написал базовый многопоточный генератор сетевого трафика и хочу выяснить, что его вызывает. заблокировать/остановить. perf top показывает много (около 25%) _raw_spin_lock_irqsave и native_queued_spin_lock_slowpath.

Когда я запускаю генератор трафика с одним рабочим потоком, прикрепленным к одному ядру ЦП, скорость передачи составляет около 6,5 Гбит/с, а ядро ​​рабочего потока работает примерно на 35%. Ядро, которое обрабатывает мягкое IRQ NET_RX (которое обрабатывает операцию очистки передаваемого трафика, так что не путайтесь в названии!) работает на 100%, поэтому кажется, что ядро ​​больше не может обрабатывать пакеты в секунду из-за к узкому месту на пути Tx внутри ядра (af_packet.c) «где-то».

Когда я запускаю приложение генератора трафика со вторым рабочим потоком, каждый поток закреплен за отдельными ядрами, каждое ядро ​​работает примерно на 35% использования. Два дополнительных ядра теперь работают на 100% для NET_RX программных IRQ, закрепленных за ними (обработка действия очистки передачи в ядре из двух рабочих потоков). Таким образом, приложение использует двойную загрузку ЦП, как и NET_RX IRQ, однако скорость передачи увеличилась только с 6,5 Гбит/с до 7 Гбит/с (увеличение использования ЦП на 100 %, но увеличение передаваемого трафика только на ~10 %), и теперь perf top Я вижу до 25% _raw_spin_lock_irqsave и native_queued_spin_lock_slowpath, поэтому мне кажется, что в ядре (в net/packet/af_packet.c) блокируется спин-блокировка или блокировка мьютекса, и я хотел бы сузить, где именно (какая именно блокировка или какой вызов функции .

Я пытался использовать SystemTap, чтобы узнать. Если кто-то осмелится проверить kernel.function("spin_lock") или raw_spin_lock/_raw_spin_lock/__raw_spin_lock и т. д., вы получите безумное количество вывода, которое трудно отсортировать, или просто полный сбой / блокировку системы. Это вполне очевидно, поскольку многие процессы используют спин-блокировки и опрашивают их.