Nanosleep высокая загрузка процессора?

Question

Я заметил, что небольшая тестовая программа, которая вызывает nanosleep, показывает огромную разницу в загрузке процессора при запуске на машинах Linux с ядром, более новым, чем 2.6.22.

#include <time.h>
int main (void)
{
    struct timespec sleepTime;
    struct timespec returnTime;
    sleepTime.tv_sec = 0;
    sleepTime.tv_nsec = 1000;
    while (1)
    {
      nanosleep(&sleepTime, &returnTime);
    }
    return 0;
}

(Да, я понимаю, что эта программа ничего не делает)

Если я скомпилирую это и запущу его на машине openSUSE 10.3 (2.6.22.19-0.2-default), программа даже не отобразится в списке процессов, сгенерированном «top», указывая мне, что он мало процессорного времени. Если я запускаю его на машине openSUSE 11.1 (2.6.27.23-0.1-default), top показывает, что программа занимает 40% процессорного времени. Работа на Fedora 9 (2.6.25-14.fc9.i686) и Fedora 10 также показала такое же высокое использование процессора в «top».

Произошло ли изменение в ядре, которое влияет на это?

Answer 1

Это связано с введением NO_HZ в основной планировщик.

Раньше ваш сон в 1000 нс обычно спал целую галочку - 1 000 000 нс. Теперь, когда машина бездействует, на самом деле она спит только за то, что вы просили. Таким образом, он выполняет цикл while () и системный вызов примерно в 1000 раз чаще, а значит, гораздо больше использует процессор. Если вы увеличите tv_nsec, вы увидите снижение загрузки процессора.

Answer 2

У меня нет однозначного ответа ... но первое, на что я бы обратил внимание, это параметры конфигурации, с помощью которых было скомпилировано ядро:

cat /boot/config-`uname -r`

Варианты, которые, на мой взгляд, могут иметь значение: CONFIG_HZ, CONFIG_HPET_TIMER и CONFIG_HIGH_RES_TIMERS. Возможно, они различаются в ваших ядрах ... это может помочь вам сузить круг.

Раньше на ядрах 2.4 было, что nanosleep был бы занят - ожидание ожидания менее 2 мс при работе в соответствии с политиками планировщика реального времени (SCHED_FIFO или SCHED_RR, см. Справочную страницу nanosleep ), но так как все ядра имеют 2.6, это, кажется, не является фактором.