linux - libreria - nanosleep uso de CPU alta?

sleep en c ubuntu

Question

Noté que un pequeño programa de prueba que llama a nanosleep muestra una gran diferencia en el uso de la CPU cuando se ejecuta en máquinas Linux con un kernel más nuevo que 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;
}

(Sí, me doy cuenta de que este programa no hace nada)

Si compilo esto y lo ejecuto en una máquina openSUSE 10.3 (2.6.22.19-0.2-default), el programa ni siquiera aparece en la lista de procesos generada por "top", lo que me indica que está usando muy poco tiempo de CPU . Si lo ejecuto en una máquina openSUSE 11.1 (2.6.27.23-0.1-default), arriba muestra que el programa toma el 40% del tiempo de la CPU. La ejecución en Fedora 9 (2.6.25-14.fc9.i686) y Fedora 10 también mostraron el mismo alto uso de CPU en "la parte superior".

Ha habido un cambio en el kernel que afecta esto?

Answer 1

Esto se debe a la introducción de NO_HZ en el planificador principal.

Anteriormente, su sueño de 1.000 ns generalmente dormía durante una marca completa: 1,000,000 ns. Ahora, cuando la máquina está inactiva, en realidad solo está durmiendo para lo que pidió. Por lo tanto, está ejecutando el ciclo while () y syscall alrededor de 1,000 veces más frecuentemente, de ahí que se use mucho más CPU. Si aumenta tv_nsec, debería ver una reducción en el uso de la CPU.

Answer 2

No tengo una respuesta definitiva ... pero lo primero que vería son las opciones de configuración con las que se compiló el kernel:

cat /boot/config-`uname -r`

Las opciones que creo que podrían ser relevantes son CONFIG_HZ , CONFIG_HPET_TIMER y CONFIG_HIGH_RES_TIMERS . Quizás esos difieren entre tus kernels ... eso puede ayudarte a reducirlo.

Solía ​​estar en núcleos 2.4 que nanosleep estaría ocupado: esperar por menos de 2 ms si se ejecuta bajo políticas de planificador en tiempo real ( SCHED_FIFO o SCHED_RR , consulte la página man de nanosleep ), pero dado que todos los kernels son 2.6, eso no ocurre Parece ser un factor.