Почему статус потока работает, но он не использует ЦП?

Сегодня обнаружил очень странную проблему. Я запускал Redhat Enterprise Linux 6 с процессором Intel E31275 (4 ядра, 8 потоков). Я обнаружил, что один поток ядра (я назвал его my_thread) работал неправильно. С помощью команды «ps» я обнаружил, что статус my_thread всегда работает:

ps ax
5545 ?        R      3:14 [my_thread]
15774 ttyS0    Ss     0:00 -bash
...

Но его продолжительность всегда была 3:14. Поскольку он работает, почему общее время не увеличилось? Из файла proc /proc/5545/sched я обнаружил, что вся статистика, включая количество пробуждений (se.nr_wakeups) для этого потока, тоже всегда была одинаковой.

В /proc/5545/stack я нашел этот поток, вызывающий эту функцию, и так и не вернулся:

interruptible_sleep_on_timeout(&q, 3*HZ);

Теоретически эта функция будет возвращаться каждые 3 секунды, если ни один другой поток не разбудит поток. Каждый раз после возврата функции значение se.nr_wakeups в /proc/5545/sched увеличивалось на 1. Но этого никогда не происходило после того, как я обнаружил, что в потоке возникли проблемы.

У кого-нибудь есть идеи? Возможно ли, что interruptible_sleep_on_timeout() никогда не возвращается?

Обновление: я обнаружил, что проблема не возникнет, если я установлю привязку ЦП к этому потоку. Если я его прикалываю к выделенному ядру, то все ок. Есть ли проблемы с планированием SMP?

Обновление еще раз: после того, как я отключил гиперпоточность в BIOS, я до сих пор не видел такой проблемы.


linux-kernel scheduler scheduling hyperthreading
person flypen    schedule 21.10.2011    source источник
comment
Что выше interruptible_sleep_on_timeout в стеке? Это поток ядра?   -  person David Schwartz    schedule 22.11.2011

Ответы (1)


arrow_upward
4
arrow_downward

Во-первых, R указывает, что поток не находится в рабочем состоянии, но готов к выполнению. То есть это не означает, что он работает, это означает, что он находится в состоянии, которое планировщик может выбрать для запуска. Между ними есть большая разница.

В аналогичном смысле interruptible_sleep_on_timeout(&q, 3*HZ); не запустит поток через 3 мгновения, а сделает его доступным для запуска после 3 мгновений - и действительно, вы видите его в "ps" как доступном для запуска, поэтому, возможно, тайм-аут действительно произошел.

Поскольку вы ничего не сказали о рассматриваемом потоке ядра, я даже не знаю, находится ли он в вашем собственном коде или в стандартном коде ядра, поэтому я не могу подробно ответить.

Одна из возможных причин описанной вами ситуации заключается в том, что какой-то другой поток (пользовательский или ядро) имеет более высокий приоритет, чем ваш поток, и поэтому планировщик никогда не выбирает его для запуска. Если это так, вероятно, это не поток, работающий с приоритетом в реальном времени (SCHED_FIFO или SCHED_RR).

person gby    schedule 21.10.2011
comment
Спасибо за ответ. Когда возникла эта проблема, система простаивала. Процент простоя ЦП был более 99%. - person flypen; 22.10.2011
comment
Обновление: я обнаружил, что проблема не возникнет, если я установлю привязку ЦП к этому потоку. Если я его прикалываю к выделенному ядру, то все ок. Есть ли проблемы с планированием SMP? - person flypen; 07.11.2011