linux - mac - musicbrainz picard español
Uso de punto flotante en el kernel de Linux (2)
Estoy leyendo el "Desarrollo del kernel de Linux" de Robert Love, y me encontré con el siguiente pasaje:
No (fácil) uso de punto flotante
Cuando un proceso de espacio de usuario utiliza instrucciones de coma flotante, el kernel gestiona la transición de un modo entero a uno de coma flotante. Lo que tiene que hacer el kernel al usar instrucciones de coma flotante varía según la arquitectura, pero normalmente el kernel atrapa una trampa y luego inicia la transición del modo entero al modo de coma flotante.
A diferencia del espacio de usuario, el kernel no tiene el lujo de un soporte sin interrupciones para el punto flotante porque no puede atraparse fácilmente. Usar un punto flotante dentro del núcleo requiere guardar y restaurar manualmente los registros de punto flotante, entre otras tareas posibles. La respuesta corta es: ¡ No lo hagas! Excepto en casos excepcionales, no hay operaciones de coma flotante en el kernel.
Nunca he oído hablar de estos modos "entero" y "punto flotante". ¿Qué son exactamente, y por qué son necesarios? ¿Esta distinción existe en arquitecturas de hardware convencionales (como x86), o es específica para algunos entornos más exóticos? ¿Qué implica exactamente una transición del modo entero al modo de coma flotante, tanto desde el punto de vista del proceso como del kernel?
Con algunos diseños de kernel, los registros de coma flotante no se guardan cuando una tarea de "kernel" o de "sistema" se cambia de tarea. (Esto se debe a que los registros FP son grandes y requieren tanto tiempo como espacio para guardarlos). Por lo tanto, si intenta usar FP, los valores serán "poof" aleatoriamente.
Además, algunos esquemas de punto flotante de hardware dependen del kernel para manejar situaciones "extrañas" (por ejemplo, división cero) a través de una trampa, y el mecanismo de trampa requerido puede estar en un "nivel" más alto que la tarea de kernel actualmente en ejecución.
Por estas razones (y un par más) algunos esquemas de FP de hardware se interceptarán cuando use una instrucción FP por primera vez en una tarea. Si se le permite usar FP, entonces se activa una bandera de coma flotante en la tarea, si no, se le dispara por el pelotón de fusilamiento.
Porque...
- muchos programas no usan punto flotante o no lo usan en ningún segmento de tiempo dado; y
- guardar los registros FPU y otros estados FPU lleva tiempo; por lo tanto
... un kernel de sistema operativo simplemente puede apagar la FPU. Presto, sin estado para guardar y restaurar, y por lo tanto, cambio de contexto más rápido. (Esto es lo que significaba el modo , simplemente significaba que la FPU estaba habilitada).
Si un programa intenta una FPU op, el programa quedará atrapado en el kernel, el kernel encenderá la FPU, restaurará cualquier estado guardado que ya exista, y luego regresará para volver a ejecutar la operación FPU.
En el momento del cambio de contexto, sabe que pasará por la lógica de guardar estado. (Y luego puede apagar la FPU nuevamente).
Por cierto, creo que la explicación del libro sobre la razón por la cual los núcleos (y no solo Linux) evitan las operaciones de FPU es ... no perfectamente exacto. 1
El kernel puede atraparse en sí mismo y lo hace por muchas cosas. (Temporizadores, fallas de página, interrupciones de dispositivos, etc.) La verdadera razón es que el kernel no necesita operaciones de FPU y también necesita ejecutarse en arquitecturas sin una FPU. Por lo tanto, simplemente evita la complejidad y el tiempo de ejecución necesarios para gestionar su propio contexto de FPU al no realizar operaciones para las que siempre hay otras soluciones de software.
Es interesante observar con qué frecuencia debería guardarse el estado de la FPU si el núcleo quería usar FP . . . cada llamada al sistema, cada interrupción, cada cambio entre hilos del kernel. Incluso si existiera la necesidad de kernel FP ocasional, 2 probablemente sería más rápido hacerlo en software.
1. Es decir, completamente equivocado.2. Hay algunos casos que conozco en los que el software kernel contiene una implementación aritmética de coma flotante . Algunas arquitecturas implementan operaciones tradicionales de FPU en hardware pero dejan algunas operaciones complejas de FP de IEEE al software. (Piénselo: aritmética normal). Cuando ocurre un caso extraño de IEEE, atrapan un software que contiene una emulación pedantemente correcta de las operaciones que pueden atrapar.