Найдите случайное ядро процессора

У меня есть ядро 2.6.35 PREEMPT, работающее на среднескоростном процессоре ARMv7. Приблизительно один раз каждые 100 - 125 с, что-то заставляет ядро не обрабатывать некоторые драйверы, связанные со звуком, достаточно быстро, чтобы избежать потерь. Задержка обычно находится в диапазоне 15-30 мс, но может быть намного дольше. Не ясно, является ли задержка полностью в ядре или может относиться к планированию пользовательского процесса, выполняющегося с приоритетом в реальном времени (SCHED_RR, 2).

Я предполагаю, что есть (по крайней мере, один) драйвер, который не играет хорошо с preempt.

Некоторые результаты, полученные в результате пользовательского процесса, иллюстрируют некоторые аспекты как нормального, так и ненормального поведения, хотя я не уверен, как интерпретировать различные отчеты о времени?

Нормальный случай:

     Опрос 0,000518 ([{fd = 10, события = POLLIN | POLLERR | POLLNVAL, revents = POLLIN}], 1, 3415) = 1 
     0.010202 опрос ([{fd = 10, события = POLLIN | POLLERR | POLLNVAL}, {fd = 6, события = POLLOUT | POLLERR | POLLNVAL, revents = POLLOUT}], 2, 3404) = 1 
     0.000585 опрос ([{fd = 10, события = POLLIN | POLLERR | POLLNVAL}, {fd = 6, события = POLLOUT | POLLERR | POLLNVAL, revents = POLLOUT}], 2, 3404) = 1 
     Опрос 0,000302 ([{fd = 10, события = POLLIN | POLLERR | POLLNVAL, revents = POLLIN}], 1, 3404) = 1 
     0.010706 опрос ([{fd = 10, события = POLLIN | POLLERR | POLLNVAL}, {fd = 6, события = POLLOUT | POLLERR | POLLNVAL, revents = POLLOUT}], 2, 3393) = 1 
     Опрос 0,000480 ([{fd = 10, события = POLLIN | POLLERR | POLLNVAL}, {fd = 6, события = POLLOUT | POLLERR | POLLNVAL, revents = POLLOUT}], 2, 3392) = 1

При опросе для вывода на fd6 не происходит блокировки, и, когда только fd10 опрашивается на вход, происходит блокировка около 10 мс. Это отражается как в отчете о продолжительности системного вызова, так и об интервале между системными вызовами (они согласованы).

Случай отказа (крайний пример):

     Опрос 0.000305 ([{fd = 10, события = POLLIN | POLLERR | POLLNVAL, revents = POLLIN}], 1, 3543) = 1 
     0.010730 опрос ([{fd = 10, события = POLLIN | POLLERR | POLLNVAL}, {fd = 6, события = POLLOUT | POLLERR | POLLNVAL, revents = POLLOUT}], 2, 3533) = 1 
     Опрос 0,000475 ([{fd = 10, события = POLLIN | POLLERR | POLLNVAL}, {fd = 6, события = POLLOUT | POLLERR | POLLNVAL, revents = POLLOUT}], 2, 3532) = 1 
     Опрос 0,000329 ([{fd = 10, события = POLLIN | POLLERR | POLLNVAL, revents = POLLIN}], 1, 3532) = 1 
     0.953349 опрос ([{fd = 10, события = POLLIN | POLLERR | POLLNVAL}, {fd = 6, события = POLLOUT | POLLERR | POLLNVAL, revents = POLLOUT | POLLERR}], 2, 2578) = 1

Обратите внимание, что в этом случае, несмотря на то, что второй по счету последний звонок записывается как 10 мс (нормальный), до последнего звонка это 953 мс.

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

kernel profiling

— авиалиния
источник

Бонусные баллы за интересный вопрос. Я не уверен, как на это ответить, но у меня есть вопрос, как отследить его до загрузки процессора (например, в отличие от всплесков в iowait)?

— Братчли

Первое предположение - если вы используете JFFS2 или YAFFS на большой NAND-вспышке, особенно если вы записываете. Отключите все, что пишет на флэш, и посмотрите, поможет ли это. Как выглядит ваша таблица процессов? Вы можете использовать ftrace в крайнем случае, если у вас есть набор инструментов для сборки ядра.

— Джонатан Бен-Авраам

sar -bu может это сделать .. linux.die.net/man/1/sar

— Grizly

Есть некоторая вспышка в использовании; SD-карта с установленной файловой системой ext4. И записи в него действительно являются возможным источником этих проблем (но почему именно?), Но, вероятно, не единственными.

— авиалиния

perfможет быть полезным для вас. Это часть утилит ядра Linux.

Например:

perf record -R -a -g fp -e cycles -e syscalls:sys_enter_poll -e syscalls:sys_exit_poll
#Just ctrl+c if you are done, and view ith
perf script

Он покажет все времена и параметры входа / выхода системного вызова (например, strace), предоставит имя двоичного файла, вызывающего системный вызов, и определит частоту вызовов стека каждого ЦП на некоторой частоте (включая символы ядра). Таким образом, вы можете увидеть, какой код был выполнен во время системного вызова. В многопроцессорной системе необходимо обратить внимание на идентификатор процессора (например, [001]).

— Zulan
источник

Я посмотрю, как создать платформу для платформы - спасибо за совет.

— авиалиния

Может быть, atopможет пролить свет на вашу проблему.

Он может отображать процессы, которые уже вышли, и может отображать загрузку процессора , памяти , диска и сети .

Вы можете запустить его в интерактивном режиме, позволить ему записывать в текстовый файл или запускать его, как sarв заданный интервал, создавая двоичный файл истории, который вы можете просмотреть позже.

Я использую его, чтобы найти свиней всех видов, которые трудно найти :-)

— trapicki
источник

Найдите случайное ядро ​​процессора

Найдите случайное ядро процессора