|
Personalizando el intervalo de temporización del kernel
|
|
Por jcantero
departamento las constantes varían, las variables no , Sección Desarrolladores
Puesto a las Sat Oct 19th, 2002 at 01:20:09 AM CET
|
 |
|
KernelTrap vuelve a profundizar en las interioridades del kernel Linux con este artículo. En él, nos acercan al parche de Robert Love que migra el código hacia atrás de los kernels de desarrollo 2.5.x hacia el 2.4, y que permite ajustar la frecuencia de la interrupción del timer (temporizador).
|
Para comprender las implicaciones que conlleva el cambio de esta frecuencia, echaremos mano de la propia explicación de Robert Love (extraida del mensaje a la lista del kernel e incluida en el artículo de KernelTrap):
"La interrupción de temporización es el corazón del sistema. Todo nace y muere basándose en ella. Su periodo es básicamente la granularidad del sistema: los temporizadores actúan en intervalos de 10ms, los intervalos de tiempo se otorgan en trozos de 10ms, etc."
Estamos hablando de, por ejemplo, el quantum o tiempo en el que entra en marcha el planificador (scheduler()) de procesos, y por lo tanto el tiempo durante el cual se ejecuta sin interrupciones una tarea (hilo, proceso,...).
Hasta ahora, la frecuencia del timer (HZ) valía 100 -en las arquitecturas 80x86-. Esto es, la interrupción de reloj se disparaba 100 veces por segundo, o dicho de otro modo, cada 1/100 de segundo (=10ms). En los nuevos kernels 2.5, después de los cambios hechos por Robert Love (encaminados a evitar dependencias y suposiciones separadas de esta variable), se ha empezado a experimentar con HZ=512 (Red Hat 8.0) o HZ=1000 -un periodo de 1ms-.
El tener una interrupción de temporización más frecuente tiene un fuerte impacto en muchas partes del sistema. Por ejemplo, las funciones de sondeo (poll(), select()) se basan en el timer, con lo que responderán más diligentemente a sus cambios de estado. También afecta, por supuesto, al planificador, que al actuar más frecuentemente, permite liberar antes el procesador de procesos bloqueados o terminados.
Relacionado con esto, es especialmente importante este cambio para el parche preemptivo, puesto que, ahora la expulsión de procesos para dar paso a otros más prioritarios, se efectuará más frecuentemente, beneficiándose de ello en especial los procesos premiados por este método (los más interactivos generalmente).
En general, aumentar la frecuencia hace disminuir la latencia del sistema, pero también tiene un coste: a más interrupciones por segundo, más carga por interrupciones. En sistemas rápidos, esto no se tiene por qué notar, pero cuidado si usamos sistemas antiguos (Pentium clásicos para abajo).
Por último, referirnos a los cambios hechos por Robert, nuevamente:
"Sin este parche, no puedes simplemente cambiar HZ, ya que el sistema exporta varios valores a través de las llamadas al sistema, o /proc, que se miden en ticks. En otras palabras, las cosas que se miden en unidades de "ticks por segundo". Y estas dependen de HZ. Así que necesitamos un mecanismo para escalar el valor de HZ del sistema y el valor de HZ que asume el espacio de usuario, que es el tradicional HZ=100. Esto es lo que hace la función jiffies_to_clock_t() en los kernel 2.5, y lo que he migrado hacia atrás".
|
|
|
