Deadline es un programador de E/S , o programador de discos, para el núcleo Linux . Fue escrito en 2002 por Jens Axboe .
El objetivo principal del planificador de fecha límite es garantizar un tiempo de inicio del servicio para una solicitud. [1] El planificador impone una fecha límite a todas las operaciones de E/S para evitar una escasez de solicitudes . Mantiene dos colas de fecha límite , así como colas ordenadas (tanto de lectura como de escritura). Las colas de fecha límite se ordenan por su tiempo de expiración, mientras que las colas ordenadas se ordenan por el número de sector.
Antes de atender la siguiente solicitud, Deadline decide qué cola utilizar. Las colas de lectura tienen mayor prioridad porque los procesos suelen bloquear las operaciones de lectura. A continuación, Deadline comprueba si la primera solicitud de la cola de fecha límite ha expirado. De lo contrario, el programador atiende un lote de solicitudes de la cola ordenada. En ambos casos, el programador también atiende un lote de solicitudes posteriores a la solicitud elegida en la cola ordenada.
De forma predeterminada, las solicitudes de lectura tienen un tiempo de expiración de 500 ms y las solicitudes de escritura expiran en 5 segundos.
En enero de 2002, Axboe publicó una versión preliminar del programador en la lista de correo del kernel de Linux. [2]
Las mediciones han demostrado que el programador de E/S de fecha límite supera al programador de E/S CFQ para ciertas cargas de trabajo de múltiples subprocesos. [3]
Deadline ejecuta operaciones de E/S (IOP) a través del concepto de "lotes", que son conjuntos de operaciones ordenadas en términos de un número creciente de sectores. Este parámetro ajustable determina el tamaño que debe tener un lote antes de que las solicitudes se pongan en cola en el disco (salvo que expire un lote creado actualmente). Los lotes más pequeños pueden reducir la latencia al garantizar que las nuevas solicitudes se ejecuten antes (en lugar de posiblemente esperar a que lleguen más solicitudes). Aun así, pueden hacerlo, pero pueden degradar el rendimiento general al aumentar el movimiento general de los cabezales de la unidad (ya que la secuenciación ocurre dentro de un lote y no entre ellos). Además, si el número de IOP es lo suficientemente alto, los lotes se ejecutarán de manera oportuna de todos modos.
El tiempo 'read_expire' es el tiempo máximo en milisegundos después del cual la solicitud de lectura se considera 'vencida'. La mejor manera de utilizar la solicitud de lectura es antes de la fecha de vencimiento. Deadline no intentará asegurarse de que todas las E/S se emitan antes de su fecha de vencimiento. Sin embargo, si la E/S ya venció, se le dará prioridad.
La cola de caducidad de lectura solo se comprueba cuando Deadline vuelve a evaluar las colas de lectura. Para las solicitudes de lectura, esto significa que se envía una solicitud de lectura ordenada (excepto en el caso de E/S de transmisión). Mientras el programador está transmitiendo E/S desde la cola de lectura, la lectura caducada no se evalúa. Si hay lecturas caducadas, se extrae la primera del FIFO. Tenga en cuenta que esta lectura caducada es el nuevo nexo para el orden de clasificación de lectura. El puntero siguiente en caché se configurará para apuntar a la siguiente E/S de la cola de clasificación después de esta caducada... Lo que hay que tener en cuenta es que el algoritmo no solo ejecuta todas las E/S caducadas una vez que han pasado su fecha de caducidad. Esto permite mantener un rendimiento razonable agrupando las lecturas ordenadas "write_starved" antes de volver a comprobar la cola de lectura caducada.
La cantidad máxima de E/S que se puede realizar entre E/S de lectura vencida es 2 * 'fifo_batch' * 'writes_starved'. Un conjunto de lecturas en streaming 'fifo_batch' después de la primera E/S de lectura vencida y, si este flujo causó la condición de escritura inactiva, es posible que se realicen otras escrituras en streaming 'fifo_batch'. Este es el peor de los casos, después del cual se volvería a evaluar la cola de lectura vencida. En el mejor de los casos, la cola de lectura vencida se evaluará 'write_starved' veces seguidas antes de omitirse porque se usaría la cola de escritura.
'write_expire' tiene la misma función que read_expire, pero se utiliza para operaciones de escritura (agrupadas en lotes separados de las solicitudes de lectura).
La fecha límite prioriza las solicitudes de lectura sobre las solicitudes de escritura, por lo que esto puede llevar a situaciones en las que las operaciones ejecutadas sean casi en su totalidad solicitudes de lectura. Esto se vuelve un parámetro de ajuste más importante a medida que write_expire se alarga o el ancho de banda general se acerca a la saturación. Reducir esto le da más ancho de banda a las escrituras (relativamente hablando) a expensas de las operaciones de lectura. Sin embargo, si la carga de trabajo de la aplicación es de lectura intensiva (por ejemplo, la mayoría de los servidores HTTP o de directorio) con solo una escritura ocasional, se puede lograr una latencia reducida de las IOP promedio al aumentar esto (de modo que se deban realizar más lecturas antes de que un lote de escritura se ponga en cola en el disco).
Una "fusión frontal" es una operación en la que el Programador de E/S, que busca condensar (o "fusionar") solicitudes más pequeñas en menos operaciones (más grandes), tomará una nueva operación y luego examinará el lote activo e intentará localizar operaciones en las que el sector inicial sea el mismo o inmediatamente posterior al sector inicial de otra operación. Una "fusión posterior" es lo opuesto, en la que se buscan sectores finales en el lote activo que sean iguales o inmediatamente posteriores a los sectores iniciales de la operación actual. La fusión desvía las operaciones del lote actual al activo, lo que disminuye la "equidad" para aumentar el rendimiento.
Debido a la forma en que se suelen distribuir los archivos, las fusiones posteriores son mucho más comunes que las fusiones frontales. Para algunas cargas de trabajo, se puede perder tiempo al intentar fusionar solicitudes frontales. Establecer 'front_merges' en 0 deshabilita esta funcionalidad. Las fusiones frontales aún pueden ocurrir debido a la sugerencia 'last_merge' almacenada en caché, pero como eso tiene un costo básicamente cero, aún se realiza. Este booleano simplemente deshabilita la búsqueda del sector frontal cuando se llama a la función de fusión del programador de E/S. Los totales de fusión de discos se registran por dispositivo de bloque en '/proc/diskstats'. [1]