Защо състоянието на нишката се изпълнява, но не използва CPU?

Днес открих много странен проблем. Пусках 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() никога да не се връща?

Актуализация: Намирам, че проблемът няма да възникне, ако задам CPU афинитет за тази нишка. Ако го прикача към специално ядро, тогава всичко е наред. Има ли проблеми с планирането на 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
Актуализация: Намирам, че проблемът няма да възникне, ако задам CPU афинитет за тази нишка. Ако го прикача към специално ядро, тогава всичко е наред. Има ли проблеми с планирането на SMP? - person flypen; 07.11.2011