En Minix 3 el driver del disco duro at wini es secuencial. No es

En Minix 3 el driver del disco duro at wini es secuencial. No es
concurrente. No toma (recibe) encargo de otras operaciones hasta
que ha acabado de atender la que está procesando.
Exponer factores a favor y en contra, ventajas e inconvenientes,
de esta decisión.
1. Si el driver es secuencial el código del driver es más sencillo, más fácil
de escribir y mantener.
2. Si tenemos un disco, con el driver concurrente no se gana paralelismo en
el hardware. Si tenemos varios discos (suponemos que la electrónica permite
su uso simultáneo) el driver concurrente permite obtener mayor rendimiento.
3. El tiempo de posicionamiento de la cabeza de lectura/escritura de
los discos es significativo. Con un driver concurrente se puede planificar el
servicio a los distintos cilindros (algoritmos ascensor o S-scan) y disminuir el
tiempo medio de servicio.
4. Si FS es el único cliente del driver de disco y espera a que acabe una
petición antes de hacer la siguiente, no se consigue nada con paralelismo en
el driver de disco.
5. La comunicación entre FS y driver de disco incluye vector-io (petición
de entrada salida de multiples bloques). El FS puede planificar el acceso (a
cilindros) de un disco.
6. Si FS (modificado?) puede hacer multiples encargos/peticiones (no
vector-io) al driver de disco, éste deberá poder limitar el número de encargos/peticiones pendientes cuando se alcance un valor máximo.
7. Si FS limita el número de encargos/peticiones, el driver de disco en
versión concurrente debe hacer receive por timout, y receive por terminación
de la operación de entrada/salida. Por otra parte (punto 6) en ocasiones
debe ignorar los mensajes de FS. Esto implica recibir mensajes de dos origenes e ignorar los mensajes de un tercer origen. Minix 3 tiene recepción
de cualquiera (any) o de una fuente. Necesitariamos ’receive selectivo’ de varias origenes. No aparece en la documentación de Minix 3. Implementarlo
supone un trabajo adicional.
8. (Como alternativa al punto 7) Podemos enviar un mensaje del tipo
’driver-ocupado,-vuelva-llamar-en-5-min.’ al FS.
9. (Como alternativa al punto 6) O se autolimita FS a un número máximo
de encargos/peticiones.
10. Un acceso con localidad (no aleatorio) aprovecha menos de la planificación de acceso a cilindros.
1
11. En caso de utilizar un simulador como Qemu, no está claro que se
aprecie una ventaja en la planificación de la cabeza de lectura/escritura. Si
se utiliza una imagen de disco, los cilindros en la simulación no tienen por
qué coincidir con cilindros reales. Y la diferencia puede ser mayor si la imagen
de disco asigna bloques según demanda.
12. La ventaja de utilizar un driver concurrente depende del perfil de uso
que se de al sistema.
13. Una modificación en el driver genérico de bloques afecta a todos los
drivers de bloques, a menos que separemos la compilación del dirver de disco
duro.
14. La planificación de las lecturas y escrituras por el driver de disco
duro interfiere con la planificación de procesos del kernel. No está claro que
el resultado esté de acuerdo con los objetivos de un administrador que en
principio sólo interviene en la politica del kernel (nice, ..). Esto afecta tanto
al driver secuencial como al concurrente, pero parece más sencillo coordinar
al FS con el kernel para gestionar prioridades que introducir gestión de las
prioridades en el driver de disco duro.
15. La ventaja del paralelismo (driver concurrente) se aprecia si se acumulan las peticiones de uso del disco. Esto parece mas probable en servidores
que en ordenadores de uso personal.
16. La mayor disponibilidad de memoria RAM resta protagonismo al disco
duro. Casi toda la información necesaria se encuentra en bufers.
17. Un mecanismo muy usado para dar servicio concurrente son los hilos
(hebras/threads) de las que Minix 3 carece (de momento).
En resumen. Un driver concurrente (parece que) es una mejora. Pero esa
mejora tiene un coste considerable. Y conviene hacerlo porque no perjudica,
y su implementación puede beneficiar a muchos usuarios. Suponemos que
Minix 3 vive largos años y que los discos duros no desaparecen en un par
de años.
Más importante es comprobar cómo a veces un cambio aparentamente
sencillo tiene múltiples implicaciones.
Este tema se debatió en tres grupos de Sistemas Operativos II, curso
2007/08. En cada grupo afloró más de una docena de consideraciones, y se
puso como objetivo ser capaz de presentar 6 elementos de argumentación.
2