linux - ultima - ¿Cómo soluciona USER_HZ el problema de escalado de jiffy?

ultima version de linux

Question

Según entiendo, la constante USER_HZ se agregó en Linux 2.6 para resolver los problemas derivados de las expectativas del valor HZ en el espacio de usuario: en versiones anteriores de Linux, cambiar el valor HZ puede causar que los valores en las aplicaciones de espacio de usuario sean involuntarios escamoso.

Estoy confundido acerca de cómo la constante USER_HZ resuelve este problema de escala. Por ejemplo, supongamos que una aplicación de espacio de usuario convierte jiffies en segundos:

long MY_HZ = sysconf(_SC_CLK_TCK);

/* num_jiffies acquired from /proc but
 * simplified to 1000 here for clarity */
long num_jiffies = 1000;

long num_seconds = num_jiffies / MY_HZ;

Dado que la aplicación de espacio de usuario determina el valor de HZ través de una llamada de sysconf , ¿no evitaría esto un problema de escalado?

Si, por otro lado, las aplicaciones de espacio de usuario tenían el valor HZ codificado en su fuente, ¿cómo una constante USER_HZ evitaría un problema de escalado? Las aplicaciones de espacio de usuario usarían sus constantes codificadas en lugar de las USER_HZ del sistema, y ​​no hay garantía de que las constantes codificadas coincidan con USER_HZ ?

Además, ¿todos los valores de USER_HZ reloj disponibles para el espacio de usuario (por ejemplo /proc ) ya están escalados a USER_HZ ? ¿Cómo sabe un programa de espacio de usuario si un valor en jiffies se escala a HZ o USER_HZ ?

Answer 1

Desde Linux Kernel Development (o versión en línea de la 2ª Edición )

En núcleos anteriores a 2.6, el cambio del valor de HZ dio como resultado anomalías en el espacio del usuario. Esto sucedió porque los valores se exportaron al espacio de usuario en unidades de tics por segundo. A medida que estas interfaces se volvieron permanentes, las aplicaciones crecieron para depender de un valor específico de HZ . En consecuencia, cambiar HZ varios valores exportados por alguna constante, sin conocimiento del espacio del usuario. El tiempo de actividad leería 20 horas cuando en realidad era dos.

Para evitar tales problemas, el kernel necesita escalar todos los valores de jiffies exportados. Hace esto definiendo USER_HZ , que es el valor de HZ que espera el espacio de usuario. En x86, porque HZ era históricamente 100, USER_HZ es 100.

Ticks-por-segundos siempre se escalaron a USER_HZ cuando se exportan al espacio de usuario.

Answer 2

USER_HZ se implementó como un compromiso: aunque el código de usuario podría tener un valor codificado diferente de USER_HZ , el kernel de Linux históricamente tenía un valor HZ de 100 , por lo que prácticamente todos los valores HZ codificados en el código de usuario existente se habían establecido en 100 .

Aquí está la esencia de lo que sucedió:

The Linux kernel used to have HZ set at a constant 100 for all
architectures. As additional architecture support was added, the HZ
value became variable: e.g. Linux on one machine could have a HZ
value of 1000 while Linux on another machine could have a HZ value
of 100.

This possibility of a variable HZ value caused existing user code,
which had hardcoded an expectation of HZ set to 100, to break due to
the exposure in userspace of kernel jiffies which may have be based
on a HZ value that was not equal to 100.

To prevent the chaos that would occur from years of existing user
code hardcoding a constant HZ value of 100, a compromise was made:
any exposure of kernel jiffies to userspace should be scaled via a
new USER_HZ value -- thus preventing existing user code from
breaking on machines with a different HZ value, while still allowing
the kernel on those machines to have a HZ value different from the
historic 100 value.

Ahora, esto deja la pregunta de por qué algunos jiffies de kernel están expuestos al espacio de usuario sin escala (por ejemplo, en /proc/timer_list ). Thomas Gleixner explica :

Todas las instancias que son API de facto, syscalls y también varios archivos en proc / deben estar en USER_HZ porque las aplicaciones de espacio de usuario dependen del valor USER_HZ.

proc / timer_list está exento de eso porque es más una interfaz de depuración que no es parte de la estricta API kernel. Y realmente queremos ver los valores reales y no los escalados USER_HZ para ese fin. Espero haber respondido a su pregunta.

Por lo tanto, todas las instancias que forman parte de la estricta API kernel están destinadas a escalar kernel jiffies a través de USER_HZ antes de la exposición al espacio de usuario, que otras instancias están exentas.

Ver también

La sección Tick ​​Rate: HZ de Linux Kernel Development Segunda edición de Robert Love