studio - Seleccionar un programador de E/S de Linux

mp3 tag linux (4)

Como se documenta en /usr/src/linux/Documentation/block/switching-sched.txt , el planificador de E / S en cualquier dispositivo de bloque en particular se puede cambiar en tiempo de ejecución. Puede haber algo de latencia, ya que las solicitudes del programador anterior se vacían antes de utilizar el nuevo programador, pero se puede cambiar sin problemas incluso cuando el dispositivo está siendo muy utilizado.

# cat /sys/block/hda/queue/scheduler noop deadline [cfq] # echo anticipatory > /sys/block/hda/queue/scheduler # cat /sys/block/hda/queue/scheduler noop [deadline] cfq

Idealmente, habría un solo planificador para satisfacer todas las necesidades. No parece existir todavía. El núcleo a menudo no tiene suficiente conocimiento para elegir el mejor planificador para su carga de trabajo:

noop suele ser la mejor opción para dispositivos de bloques respaldados por memoria (p. ej. ramdisks) y otros medios no rotativos (flash) donde intentar reprogramar E / S es un desperdicio de recursos
deadline es un programador liviano que intenta poner un límite estricto a la latencia
cfq intenta mantener la equidad del ancho de banda de E / S en todo el sistema

El valor predeterminado fue anticipatory durante mucho tiempo y recibió mucha afinación, pero se eliminó en 2.6.33 (principios de 2010). cfq convirtió en el predeterminado hace algún tiempo, ya que su rendimiento es razonable y la equidad es un buen objetivo para los sistemas multiusuario (e incluso para los escritorios de un solo usuario). Para algunos escenarios, las bases de datos se usan a menudo como ejemplos, ya que tienden a tener sus propios patrones peculiares de programación y acceso, y son a menudo el servicio más importante (¿a quién le importa la equidad?): anticipatory tiene una larga historia de ser Ajustable para un mejor rendimiento en estas cargas de trabajo, y la deadline pasa muy rápidamente todas las solicitudes hasta el dispositivo subyacente.

Leí que supuestamente es posible cambiar el planificador de E / S para un dispositivo en particular en un kernel en ejecución al escribir en / sys / block / [disk] / queue / scheduler. Por ejemplo, puedo ver en mi sistema:

anon@anon:~$ cat /sys/block/sda/queue/scheduler noop anticipatory deadline [cfq]

que el valor predeterminado es el planificador de colas completamente justo. Lo que me pregunto es si hay algún uso al incluir los cuatro programadores en mi kernel personalizado. Parecería que no tiene mucho sentido tener más de un planificador compilado a menos que el kernel sea lo suficientemente inteligente como para seleccionar el programador correcto para el hardware correcto, específicamente el programador ''noop'' para unidades basadas en flash y uno de los otros para un sistema tradicional disco duro.

¿Es este el caso?

El kernel de Linux no cambia automáticamente el programador IO en tiempo de ejecución. Con esto quiero decir, el kernel de Linux, a partir de hoy, no puede elegir automáticamente un planificador "óptimo" según el tipo de dispositivo de almacenamiento secundario. Durante la puesta en marcha o durante el tiempo de ejecución, es posible cambiar el programador IO manualmente .

El planificador predeterminado se elige al inicio según el contenido del archivo ubicado en /linux-2.6 /block/Kconfig.iosched . Sin embargo, es posible cambiar el planificador IO durante el tiempo de ejecución haciendo echo de un nombre de planificador válido en el archivo ubicado en / sys / block / [DEV] / queue / scheduler. Por ejemplo, echo deadline > /sys/block/hda/queue/scheduler

El objetivo de tener soporte para kernel diferentes es que puedes probarlos sin reiniciar; luego puede ejecutar cargas de trabajo de prueba a través de sytsem, medir el rendimiento y luego convertirlo en el estándar para su aplicación.

En el hardware moderno para servidores, solo el noop parece ser útil. Los otros parecen más lentos en mis pruebas.

Es posible utilizar una regla udev para permitir que el sistema decida sobre el programador en función de algunas características del hw.
Una regla de udev de ejemplo para SSD y otras unidades no rotativas podría parecerse

# set noop scheduler for non-rotating disks ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

dentro de un nuevo archivo de reglas de udev (por ejemplo, /etc/udev/rules.d/60-ssd-scheduler.rules ). Esta respuesta se basa en la wiki.debian.org/SSDOptimization#Low-Latency_IO-Scheduler

Para verificar si los discos ssd usarían la regla, es posible verificar el atributo desencadenante por adelantado:

for f in /sys/block/sd?/queue/rotational; do printf "$f "; cat $f; done