Почему статус потока работает, но он не использует процессор? - PullRequest
Новая
       34

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

2 голосов
/ 21 октября 2011

Сегодня я обнаружил очень странную проблему. Я запускал 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 такой проблемы до сих пор не было.

1 Ответ

4 голосов
/ 21 октября 2011

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

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

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

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

...