Feeds, issues, packages and code source about emulation and pograming, of VENENUX proyects, Debian related distros and massenkoh!

I/O linux kernel shedulers and parameters


SHORT VERSION: at end click here


Choosing an I/O Scheduler for linux, if have¡¡¡¡

VERSION CORTA: al final click aqui


Elegir un modo para el Programador I/O de Linux, si tienen ¡¡¡¡

There are primarily three available I/O schedulers (also known as "elevator policies"), these decide the order in which read and write requests are serviced by the block devices, and these are not to be confused with the thread scheduler, which allocates CPU time to threads and processes. These are selected at boot time via the "elevator" kernel parameter, but in 2.6 new are introduced new noop mode, lest see all.

An I/O Scheduler its a way of handle reading of data from any block devices, even the main memory, this also including wsap file area¡ The Linux kernel, the core of the operating system, is responsible for controlling disk access by using kernel I/O scheduling. Can now optimize the kernel I/O at boot time, by selecting one of four different I/O schedulers to accommodate different I/O usage patterns:

Hay primeramente tres programadores DE E/S (también conocido como "políticas de ascensor"), estos deciden el orden de peticiones para leer y escribir y como son atendidas por los dispositivos de bloque, no debe ser confundido con el programador de hilos, que asigna tiempo de CPU para procesos. Estos se seleccionan en el arranque a través del parámetro del kernel "elevator", pero en 2.6 se introduce el nuevo modo noop, veamos que es todo.

Un Programador de E/S es la forma de manejar la lectura de los datos de los dispositivos de bloque, incluyendo la memoria principal, y tambien el área de intercambio¡ El kernel de Linux, el núcleo del sistema operativo, es responsable de controlar el acceso al disco usando planeacion de E/S programada. Ahora puede optimizar el núcleo de E/S durante el arranque, seleccionando uno de los cuatro que diferentes programadores E/S para dar cabida a diferentes patrones de uso:

  • Completely Fair Queuing-elevator=cfq (most recommended for servers on gread mem)

  • Deadline-elevator=deadline (better for lower I/O activity and cached, good for sata)

  • NOOP-elevator=noop (asumes one host device, and secuencial ordened access)

  • Anticipatory-elevator=as (default linux, and compilations that not know nothing, for old devices)

WARNING¡¡ this is not as its, only work if compiled kernel havs built-in describet in config¡¡¡ this are algorithms that developers and researchers have shared with the open-source community as of mid-2004¡

  • Completely Fair Queuing-elevator=cfq (mas recomendado para servidores con gran memoria)

  • Deadline-elevator=deadline (mejor para bajo performance y escritorios, bueno en sata)

  • NOOP-elevator=noop (asume un solo bus, secuencial y un solo dispositivo)

  • Anticipatory-elevator=as (el por defecto en linux, y compilaciones de los que no saben nada, para disp viejos)

ADVERTENCIA ¡¡esto no es tan facil, solo estan si el kernel compilado TIENE lo configurado en el config ¡¡¡esto son los algoritmos que los desarrolladores y los investigadores han compartido con la comunidad de código abierto a mediados de 2004¡



The Completely Fair Queuing (CFQ) maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. CFQ is well suited for mid-to-large multi-processor systems and for systems which require balanced I/O performance over multiple LUNs and I/O controllers. This is likely to introduce additional seeking and reduce throughput off the disk, but will cause applications that need data in a short amount of time to be satisfied as long as the disk can keep up. As with the anticipatory I/O scheduler, this also borrows the basic policy from the deadline scheduler. This for multimedia systems and for well all nkown all developers, commonly almost all linux users... of course, need a powered truely real-time kernel capable, due stability priority are not chossen on debian but prior on massenkoh, recommended for gentoo funtoo espacial realtime kernels.

El Completely Fair Queuing (CFQ) mantiene escalabilidad por proceso de E/S y la cola de los intentos de distribuir el ancho de banda en partes iguales entre todas las solicitudes de E/S. CFQ es muy adecuado para sistemas multi-procesador medio a gran rango y para los sistemas que requieren E/S equilibrada en multiples controladores LUNs y E/S. Es como introducir indices de busqueda de rendimiento disco reducido, pero con aplicaciones de acceso a datos en corto periodo de tiempo satisfechos, mientras que el disco se mantiene a ritmo. Al igual que con el anticipatory I/O scheduler, este también toma prestado política de el deadline scheduler. Este es para los sistemas multimedia y casi todos los desarrolladores, generalmente casi todos los usuarios de linux ... por supuesto, este tipo de programador requiere un verdadero kernel en tiempo-real, debia se va por estabilidad, pero recomendado paraun geento o funtoo con tiempo real.

The Deadline (deadline) elevator uses a deadline algorithm to minimize I/O latency for a given I/O request, provides near real-time behavior and uses a round robin policy to attempt to be fair among multiple I/O requests and to avoid process starvation. Using five I/O queues, this scheduler will aggressively re-order requests to improve I/O performance. This its the default on massenkoh agressivbe powered kernels.This is best for workloads where there isn't much sequential access or predictability, such as is found with a database or fileserver (operations are inside on db files), also good for storage where the hardware may reorder accesses, as with command queuing as found with SCSI and Serial ATA devices, and also where simultaneous accesses to multiple regions of the device may occur, such as with RAID and JBOD arrays.

La Deadline (deadline) elevator utiliza un algoritmo de fin de linea para minimizar la latencia de E/S para una determinada solicitud de E/S, ofrece comportamiento casi de tiempo real y utiliza una política de round robin para tratar de ser justos entre múltiples solicitudes de I / O y evitar proceso de inanicion. Usando cinco colas de E/S este reordena agresivamente las peticiones para optimizar las E/S. Esta por defecto en massenkoh kernels. Este es el mejor para cargas de trabajo donde no hay mucho acceso sequencial o predictibilidad, como los en una base de datos o servidor de archivos (las operaciones se encuentran dentro de los archivos db), bueno para almacenamiento en hardware puede reordenar los accesos, como en cola de comandos que se encuentran con SCSI y dispositivos Serial ATA, y también en accesos simultáneos a múltiples regiones del dispositivo puede ocurrir, por ejemplo con RAID y JBOD.

The NOOP (noop) scheduler is a simple FIFO as secuencial ordened queue and uses the minimal amount of CPU/instructions per I/O to accomplish the basic merging and sorting functionality to complete the I/O. It assumes performance of the I/O has been or will be optimized at the block device (memory or disk) or with an intelligent host bus adapter or externally attached controller. This its very delicated due that asumes a one only exclusive host scsci controler to the hardware disk related associated. Contrary to many stupids info, this its only used for special devices, on lower hardware does nothing performance.

El planificador NOOP (noop) es un planificador FIFO simple como cola ordenada secuencial y utiliza la mínima cantidad de CPU/instrucciones por E/S de base para lograr la fusión entre funcionalidades basica y minima de E/S. Asume el rendimiento de la E/S es o sera optimizada en el dispositivo de bloque (memoria o disco) o con en un adaptador de bus inteligente o controlador externo. Estemodo es delicado ya que asume una unica controladora exclusiva scsci para con el dispositivo hardware asociado. Contrariamente muchas infos estupidas, esto solo se utiliza para dispositivos especiales, en hardware de escritorio no hay gran rendimiento.

The Anticipatory (antycipatory) elevator introduces a controlled delay before dispatching the I/O to attempt to aggregate and/or re-order requests improving locality and reducing disk seek operations. The anticipatory I/O scheduler is substantially similar to the deadline I/O scheduler and is, in fact, the default elevator policy for the kernel normaly. This is primarily because of the fact that after processing a sequence of read requests, instead of then going and servicing any outstanding write requests, it will wait for up to 6ms for additional read requests to service. This algorithm is intended to optimize systems with small or slow disk subsystems. One artifact of using the AS scheduler can be higher I/O latency. Is recomended for systems that not havemuch disk access and work in brute memory. Ist default in massenkoh and future venenux sarisari live cd mode only if used toram parameter.

El ascenso de anticipacion (antycipatory) introduce un retardo controlado antes de atender la E/S para tratar de agregar y/o reordenar las solicitudes, mejorando la locacion y reducción operaciones de búsqueda. El anticipatory I/O scheduler es sustancialmente similar al deadline I/O scheduler y, de hecho, la política de ascensor por defecto del núcleo normalmente. Esto se debe por el hecho de que después de procesar una secuencia de solicitudes de lectura, en vez de ir a continuar el servicio de todas las solicitudes de escritura, esperara durante un máximo de 6 ms para las peticiones de lectura adicionales. Este algoritmo está destinado a optimizar los sistemas con subsistemas de disco pequeño o lento. Pero usar este genera mayor latencia de E/S. Se recomienda para sistemas que no tiene mucho acceso al disco y pueden hacer trabajo en la memoria bruta. Es el de massenkoh y futuros sarisari venenux live cd si se utiliza el parámetro toram.



For very huge amoung big memory capable desktops systems, recomended cfq, especialy if have a lot of devices multiple accesss, example, a datastorage cluster server o simply a machine with many disk devices access.

For multimedia envoirements, must use realtime kernels and deadline mode, mandatory, but mantain stability.

For server configurations, depends, antocypatory are good on database clusters, especialy if use a lot of cached on main memory, but if used many swaping tecniques, must improve on cfq mode. On file access must try wel done compiled rt kernel with deadline, for subversion or data storage access.

For especial mini devices or exclusive attacheds, can use the new featured noop, that requires the device are the only in the bus attached.

Must read /usr/src/linux/Documentation/block/as-iosched.txt for complete full detailed info, carefully on compilation kernels, depending of choices, special flavors and related alwas change, but as like debian or similar genric stay on deadline or CFQ modes.

Para sistemas de grandes cantidades de memoria, recomendado el modo cfq, especialmente si tiene muchos dispositivos con multiples accesos, ejemplo clusteres de datos o una simple maquina con varios discos accediendo al mismo tiempo.

Para entornos multimedia, debe usarse kernels de tiempo real, y el modo deadline,pero cuidando la estabilidad.

Para configuraciones servidores, depende, anticipatory es bueno en clusters de base de datos, especialmente si use una gran cache en memoria principal, pero si usa mucho memoria virtual debera usarse cfq. Para aceso de ficheros, se puede intentar un nucleo rt con modo deadline, por ejemplo para subversion o almacenamiento de acceso.

En el caso de especiales y esclusividades, puede usarse el nuevo modo noop, este requiere el dispositivo tenga todo el bus dedicado a el, y sea el unico en el.

Debe leer /usr/src/linux/Documentation/block/as-iosched.txt para completar información detallada, cudidandosamente sobre las compilaciones de nucleos, dependiendo de las opciones, sabores especiales y cambios relacionados, pero como debian o similares los kernels estan en modos deadline o CFQ.