[ ARTICULO ] Guía sobre gobernadores e I/O Scheduler....

Antes de nada agradecer a Franq36 el curro que se ha pegado para recopilar y explicar esta guía.

FUENTE http://www.esp-desarrolladores.com/s...ead.php?t=2327

GOBERNADORES

1: OnDemand
2: OndemandX
3: Performance
4: Powersave
5: Conservative
6: Userspace
7: Min Max
8: Interactive
9: InteractiveX
10: Smartass
11: SmartassV2
12: Scary
13: Lagfree
14: Smoothass
15: Brazilianwax
16: SavagedZen
17: Lazy
18: Lionheart
19: LionheartX
20: Intellidemand
21: Hotplug
22: Lulzactive
23: Lulzactiveq
24: Pegasusq y su configuracion interna (link)
25: badass
26: virtuous

1: El gobernador OnDemand:

 Cita:

Este gobernador tiene un gatillo para impulsar la velocidad de reloj a la velocidad máxima fijada por el usuario. Si la carga de la CPU colocado por el usuario disminuye, el gobernador OnDemand lentamente un paso atrás a lo largo de Steppings frecuencia del núcleo hasta que se instale en su frecuencia más baja posible, o si el usuario ejecuta otra tarea para exigir una rampa.


OnDemand tiene fluidez interfaz excelente debido a su alta frecuencia de sesgo, pero también puede tener un efecto relativamente negativo en la vida de la batería en comparación con otros gobernadores. OnDemand es comúnmente elegido por los fabricantes de teléfonos inteligentes, ya que es bien probada, fiable y prácticamente garantiza el rendimiento más suave posible para el teléfono. Esto es así porque los usuarios son mucho más propensos a quejarse de rendimiento de lo que son las últimas horas de vida de batería adicional otro gobernador podría haberlos concedido.


Esto último es importante saber antes de leer sobre el gobernador interactivo: escalas OnDemand su clockspeed en un contexto cola de trabajo. En otras palabras, una vez que la tarea que dispara la rampa de velocidad de reloj está terminado, OnDemand intentará moverse de nuevo a la velocidad de reloj mínima. Si el usuario ejecuta otra tarea que desencadena rampa OnDemand, la velocidad de reloj se recuperará desde el mínimo hasta el máximo. Esto puede ocurrir especialmente frecuente si el usuario es multi-tarea. Esto también tiene implicaciones negativas para la vida de la batería.

2: OndemandX:

 Cita:

Básicamente un ondemand con suspensión / perfiles vigilia. Este gobernador se supone que es un ondemand amable batería. Cuando la pantalla está apagada, la frecuencia máxima está limitada a 500 mhz. A pesar de que el gobernador ondemand es por defecto en muchos núcleo y se considera seguro / estable, el apoyo a ondemand / ondemandX depende de la capacidad de CPU para hacer el cambio de frecuencia rápida, que son las transiciones de latencia muy baja frecuencia. He leído en alguna parte que el rendimiento del ondemand / ondemandx fueron significativamente diferentes variables para i / o programadores. Esto no es cierto para la mayoría de los otros gobernadores. Personalmente, creo ondemand / ondemandx va mejor con SIO I / O planificador.

3: Gobernador Performance:

 Cita:

Esto bloquea la CPU del teléfono a la frecuencia máxima. Si bien esto puede sonar como una idea horrible, hay cada vez más pruebas que sugieren que la ejecución de un teléfono a su frecuencia máxima en todo momento, permitirá una más rápida carrera hacia inactivo. Carrera a ralentí es el proceso por el cual un teléfono termine una tarea determinada, como la sincronización de correo electrónico, y devuelve la CPU a la extremadamente eficiente bajo el poder del Estado. Esta operación requiere de extensas pruebas, y un kernel que implementa correctamente una determinada CPU C-estados (estados de baja energía).

4: Gobernador powersave:

 Cita:

Lo contrario del gobernador de performance, el gobernador powersave bloquea la frecuencia de la CPU en el conjunto de frecuencia más baja por el usuario.

5: El gobernador conservative:

 Cita:

Esto empuja el teléfono a preferir el más bajo posible clockspeed tan a menudo como sea posible. En otras palabras, una carga más grande y más persistente se debe colocar en la CPU antes de que el gobernador conservador se le solicitará que elevar la CPU clockspeed. Dependiendo de cómo el desarrollador ha puesto en marcha este gobernador, y el mínimo clockspeed elegido por el usuario, el gobernador conservador puede introducir rendimiento entrecortado. Por otro lado, puede ser bueno para la vida de la batería.


El gobernador conservador también es frecuentemente descrito como un "OnDemand lento", si eso ayuda a dar una imagen más completa de su funcionalidad.

6: Gobernador userspace:

 Cita:

Este gobernador, excepcionalmente raro que el mundo de los dispositivos móviles, permite que cualquier programa ejecutado por el usuario para ajustar la frecuencia de la CPU operativo. Este gobernador es más común entre los servidores o PCs de escritorio donde una aplicación (como una aplicación de perfil de potencia) necesita privilegios para configurar la CPU clockspeed.

7: Min Max

 Cita:

este gobernador hace uso de sólo minimos y frecuencia máxima en base a la carga de trabajo ... no se utilizan frecuencias intermedias.

8: El gobernador interactive:

 Cita:

Al igual que el gobernador OnDemand, la CPU gobernador interactivo escalas clockspeed dinámicamente en respuesta a la carga de trabajo de la CPU por el usuario. Aquí es donde terminan las similitudes. Interactive es significativamente más sensible que OnDemand, porque es más rápido en la escala de frecuencia máxima.


A diferencia de OnDemand, que como se recordará escalas de velocidad de reloj en el contexto de una cola de trabajo, las escalas de la velocidad de reloj interactivos a lo largo de un contador de tiempo establecido arbitrariamente por el desarrollador del kernel. En otras palabras, si una aplicación requiere una rampa a velocidad de reloj máxima (100% mediante la colocación de la carga en la CPU), un usuario puede ejecutar otra tarea antes de que el regulador restablezca la reducción de la frecuencia de CPU. Esto puede eliminar el rebote frecuencia discutido en la sección OnDemand. A causa de este temporizador, Interactive es también mejor preparados para utilizar clockspeeds intermedias que se sitúan entre las frecuencias de CPU mínimo y máximo. Este es otro de los beneficios pro-vida de la batería de Interactive.


Sin embargo, debido interactivo se le permite dedicar más tiempo a la frecuencia máxima de OnDemand (por razones de rendimiento del dispositivo), los beneficios de ahorro de batería mencionados anteriormente son efectivamente negada. Larga historia corta, Interactive ofrece un mejor rendimiento que los OnDemand (algunos dicen que el mejor rendimiento de cualquier gobernador) y duración de la batería indistinguibles.


Interactivo también hace la suposición de que un usuario que la pantalla en breve será seguido por el usuario que interactúa con alguna aplicación en su dispositivo. Debido a esto, en la pantalla activa una rampa a máxima velocidad de reloj, seguido por el comportamiento del temporizador se ha descrito anteriormente.

9: Gobernador InteractiveX:

 Cita:

Creado por el desarrollador del kernel "Imoseyon", el gobernador InteractiveX se basa en gran medida en el gobernador interactivo, mejorado con los parámetros de temporización afinados a la batería de mayor equilibrio frente a rendimiento. Característica que define el gobernador InteractiveX, sin embargo, es que bloquea la frecuencia de la CPU a la más baja velocidad definida del usuario cuando la pantalla está apagada.

10: Smartass

 Cita:

Se basa en el concepto de que el gobernador interactivo.
Siempre me he acordado de que en teoría la forma en que funciona interactivos - por hacerse cargo del bucle inactivo - es muy atractivo. Nunca he conseguido que retocarlo para que se comportara decentemente en la vida real. Smartass es una reescritura completa del código y mucho más. Creo que es un éxito. El rendimiento es a la par con la "vieja" minmax y creo que listillo es un poco más sensible. Duración de la batería es difícil de cuantificar con precisión, pero sí pasar mucho más tiempo en las frecuencias más bajas.
Smartass también limitar la frecuencia máxima cuando se duerme a 352Mhz (o si su frecuencia mínima es superior a 352 - por qué -?! Va a rematar a su frecuencia min). Tomemos por ejemplo el núcleo 528/176, se dormirá en 352/176. No hay necesidad de perfiles de sueño más! "

11: SmartassV2:

 Cita:

La versión 2 del gobernador smartass original de Erasmux. Otro de los favoritos para muchos un pueblo. El objetivo gobernador de una "frecuencia ideal", y la rampa hasta más agresiva hacia esta frecuencia y menos agresivo después. Utiliza diferentes frecuencias ideales para la pantalla y fuera de la pantalla, es decir, awake_ideal_freq y sleep_ideal_freq. Esto escalas gobernador para abajo CPU muy rápido (para golpear sleep_ideal_freq pronto) mientras la pantalla está apagada y escala hasta rápidamente a awake_ideal_freq (500 mhz para GS2 por defecto) cuando la pantalla está encendida. No hay límite superior para la frecuencia, mientras que la pantalla está apagada (a diferencia Smartass). Así que el rango de frecuencia completo está disponible para el gobernador de usar durante pantalla en pantalla y estado de cierre. El lema de este gobernador es un equilibrio entre el rendimiento y la batería.

12: Scary

 Cita:

Un nuevo gobernador escribió sobre la base de conservador con algunas características smartass, se escala de acuerdo a las leyes de los conservadores. Por lo tanto, se iniciará desde la parte inferior, tomar una muestra de la carga, si está por encima de la upthreshold, rampa hasta una sola velocidad a la vez, y la deceleración de una en una. Automáticamente será la culminación de las velocidades fuera de la pantalla a 245Mhz, y si su frecuencia min es superior a 245mhz, se restablecerá el min a 120MHz, mientras que la pantalla está apagada y restaurarla al despertar de pantalla, y aún la escala de acuerdo a las leyes de los conservadores. Así que pasa la mayor parte de su tiempo a bajas frecuencias. El objetivo de esto es conseguir la mejor vida de la batería con un rendimiento decente. Le dará el mismo rendimiento que conservador en este momento, lo conseguirá con el tiempo ajustado.

13: Lagfree:

 Cita:

Lagfree es similar a ondemand. La principal diferencia es que es la optimización de la batería sea más agradable. La frecuencia se graciosamente disminuyó y, a diferencia de ondemand que salta a 100% con demasiada frecuencia. Lagfree no se salta ningún paso de frecuencia, mientras que escalar hacia arriba o hacia abajo. Recuerde que si hay un requisito para la repentina explosión de energía, lagfree que no puede satisfacer ya que tiene que elevar la CPU a través de cada paso de frecuencia más alta de corriente. Algunos usuarios informan de que la reproducción de vídeo utilizando lagfree tartamudea un poco.

14: Smoothass:

 Cita:

Al igual que el Smartass "gobernador", pero mucho más agresivo y en general éste tiene una mejor vida de la batería que es aproximadamente un tercio más que núcleos existentes

15: Brazilianwax:

 Cita:

Similar a smartassV2. Rampa más agresiva, por lo que más rendimiento, menos batería

16: SavagedZen:

 Cita:

Otro gobernador basada smartassV2. Logra un buen equilibrio entre el rendimiento y la batería en comparación con brazilianwax.

17: Lazy:

 Cita:

Este gobernador de Ezekeel es básicamente una ondemand con un min_time_state parámetro adicional para especificar el tiempo mínimo de CPU se mantiene en una frecuencia antes de escalar hacia arriba / abajo. La idea aquí es eliminar cualquier inestabilidades provocadas por la conmutación de frecuencia rápida por ondemand. Encuestas Lazy gobernador ondemand con más frecuencia que los cambios de frecuencia, pero sólo después de completar min_time_state en un intervalo de paso de muestreo superior. Lazy también tiene un parámetro screenoff_maxfreq que cuando está activado hará que el gobernador para seleccionar siempre la máxima frecuencia mientras la pantalla está apagada.

18: Lionheart:

 Cita:

Lionheart es un gobernador conservador con sede en la que se basa en la fuente Update3 de Samsung.
Los parámetros ajustables (tales como los umbrales y la tasa de muestreo) se cambiaron de modo que el gobernador se comporta más como el rendimiento de uno, a costa de la batería como la escala es muy agresivo.

19: LionheartX

 Cita:

LionheartX se basa en Lionheart, pero tiene algunos cambios en los valores ajustables y cuenta con un perfil de suspensión basado en Smartass gobernador.

20: Intellidemand:

 Cita:

Intellidemand alias Ondemand inteligente de imitación es un nuevo gobernador que se basa en ondemand. A diferencia de lo que algunos usuarios creen, este gobernador no es el sustituto de OC Daemon (Tener gobernadores diferentes de sueño y vigilia). El intellidemand originales se comporta de manera diferente según el uso de GPU. Cuando la GPU está muy ocupado (juegos, mapas, benchmarking, etc) intellidemand comporta como ondemand. Cuando GPU es 'ralentí' (o moderadamente ocupado), intellidemand limita la frecuencia máxima a un paso dependiendo de las frecuencias disponibles en el dispositivo / kernel para ahorrar batería. Esto se denomina modo de navegación. Podemos ver algunas "huellas" de gobernador interactivo aquí. Frecuencia ampliación decisión se basa en el tiempo de inactividad de la CPU. Reducir el tiempo de inactividad (<20%) hace que la CPU para aumentar la escala de la frecuencia actual. Frecuencia escala descendente que ocurre en pasos = 5% de la frecuencia máx. (Este parámetro sólo es ajustable en la conservadora, entre los gobernadores populares)
En resumen, este es un ondemand inteligente que entra en modo de navegación para limitar la frecuencia máxima cuando la GPU está al ralentí, y (salidas de modo de navegación) se comporta como ondemand cuando la GPU está ocupado, para ofrecer un rendimiento para juegos y tal. Intellidemand no salta a la frecuencia más alta cuando la pantalla está apagada.

21: Hotplug Gobernador:

 Cita:

El gobernador Hotplug se comporta muy similarmente al gobernador OnDemand, con la ventaja añadida de ser más preciso sobre la forma en que se baja a través de la tabla de frecuencias del núcleo como el gobernador mide la carga de CPU del usuario. Sin embargo, la característica que define el gobernador Hotplug es su capacidad para convertir los núcleos de CPU no utilizados fuera de los períodos de bajo uso de CPU. Esto se conoce como "conexión en caliente".


Obviamente, este gobernador sólo está disponible en dispositivos multi-core.



http://androidforums.com/xperia-mini...explained.html

22: Lulzactive

 Cita:

Este nuevo hallazgo de Tegrak se basa en los gobernadores interactivos y Smartass y es uno de los favoritos.
Old Version: Cuando la carga de trabajo es mayor que o igual a 60%, las escalas gobernador hasta CPU para siguiente escalón más alto. Cuando la carga de trabajo es menor que 60%, escalas gobernador CPU hacia abajo a la siguiente etapa inferior. Cuando la pantalla está apagada, la frecuencia está bloqueado a la frecuencia global mínimo de escala.
Nueva Versión: Tres más parámetros configurables por el usuario: inc_cpu_load, pump_up_step, pump_down_step. A diferencia de la versión anterior, ésta da más control para el usuario. Podemos establecer el umbral en el que el gobernador decide escalar hacia arriba / abajo. También puede fijar el número de pasos de frecuencia a ser omitido mientras sondea arriba y hacia abajo.
Cuando la carga de trabajo mayor o igual a inc_cpu_load, gobernador escalas CPU pump_up_step intensifica. Cuando la carga de trabajo es inferior a inc_cpu_load, gobernador CPU escalas por las escaleras pump_down_step abajo.
Ejemplo:
Considerar
inc_cpu_load = 70
pump_up_step = 2
pump_down_step = 1
Si la frecuencia actual = 200, Cada nosotros up_sampling_time si la carga de CPU> = 70%, cpu se escala hasta 2 pasos - a 800.
Si la frecuencia actual = 1200, Todos somos down_sampling_time si la carga de cpu <70%, la CPU ha sido reducida un paso - a 1000.

23: Lulzactiveq

 Cita:

Lulzactiveq es un gobernador modificado lulzactive escrito por XDA miembro robertobsc y se adapta en Siyah kernel para GS2 GS3 y. Lulzactiveq tiene como objetivo optimizar la segunda versión de luzactive de Tegrak por a) proporcionar un parámetro adicional (dec_cpu_load) para escalar hacia abajo más sensible, y b) la incorporación de la lógica de conexión en caliente para el gobernador. Luzactiveq es el primer gobernador interactivo basado siempre con la lógica intrínseca conexión en caliente (al menos la primera de su tipo para la plataforma Exynos). Cuando la CPU sale del bucle de inactividad y es el momento de tomar una decisión de escala, si la carga> = inc_cpu_load CPU se escala hacia arriba (como luzactiveq original) y si la carga <dec_cpu_load, CPU ha sido reducida. Esto posiblemente elimina la estricta sola frecuencia de corte para luzactiveq para tomar decisiones de CPU de escala. Además, destacan lógica hotplug ejecuta como un hilo separado con el gobernador para que la lógica hotplugging externa no es necesaria para controlar hotplug de entrada y salida (activar y desactivar) núcleos de CPU de núcleo múltiple en dispositivos como GS2 GS3 o. Sólo un gobernador consciente núcleo múltiple tiene sentido real en muti-core dispositivos. Lulzactiveq y pegasusq pretende hacer eso

.


24: Pegasusq

 Cita:

Su configuración interna del gobernador.
Pegasusq es básicamente un gobernador ondemand base que también controla conexión en caliente....

lo pongo en link por no hacer inmenso el post jejej
http://forum.xda-developers.com/show...03&postcount=3

25: badass

 Cita:

Badass elimina todo esto "pico rápido" a la frecuencia máxima. En un sistema típico de la CPU no pasará por encima de 918Mhz, por lo que mantener la calma y utilizará menos energía. Para provocar un aumento de la frecuencia, el sistema debe ejecutar un bit @ 918Mhz con carga alta, entonces la frecuencia se dispara a 1188Mhz. Si eso no es suficiente que el gobernador le da la máxima aceleración. (esta transición no debe durar más de 2-5 segundos, dependiendo de la carga de su sistema está experimentando) Badass también tendrá la carga de GPU en consideración. Si el gpu es moderadamente lleno que pasará por alto la comprobación anterior y el reloj de la CPU con 1188Mhz. Si el gpu es aplastado bajo carga, badass levantará las restricciones a la cpu.

26: virtuous gobernador

 Cita:

Estableció su CPU máximo para despertar y el sueño y los cambios del gobernador cuando el dispositivo está despierto o dormido. Se ahorra batería al reducir ruidos cpu mientras el dispositivo duerme, cuando se despierta, automáticamente se acelera de nuevo. O alternativamente, se puede establecer el cpu.It se basa en smartassV2 (Se utilizan dos governors.one para dormir y otra para despertarse)

El gobernador, que es para el rendimiento y la duración de la batería smartassV2 (Para obtener el máximo rendimiento, utilice ondemand o conservador

también podéis consultar mas info sobre gobernadores y tweaks en este post de xda...pero ojo que es de un samsung pero la "base de la información" que es lo que buscamos es la misma...
http://forum.xda-developers.com/show....php?t=1369817

I/o schedulers


“¿Para qué sirve un I/O Scheduler?”

 Cita:

Para entenderlo de una forma más simple: el kernel controla los accesos al disco usando un I/O Scheduler (Scheduler = planificador).

“¿Qué metas persigue cada I/O scheduler para tratar de conseguir un equilibrio?”

 Cita:

Reducir al mínimo la latencia de búsqueda del disco duro.
Dar prioridad a las operaciones de I/O de algunos procesos.
Asignar más espacio en disco para los procesos en ejecución.
Garantizar que ciertas peticiones se ejecutan antes de un tiempo límite.
Equidad (que cada proceso tenga su parte asignada de acceso al disco).
Rendimiento (tratar de atender las solicitudes que se encuentren en primer lugar, haciendo la búsqueda más rádida).
Tiempo real (garantizar que las solicitudes son atendidas en un tiempo dado).

1) Noop

 Cita:

Gestiona todas las peticiones siguiendo el método FIFO (First In First Out), o dicho de otra forma, las primeras en llegar son las primeras en salir/ser atentidas. Lo mejor es utilizarlo con dispositivos de almacenamiento que no dependen de movimiento mecánico para acceder a los datos (si, como nuestras tarjetas flash). La ventaja aquí es que las unidades flash no requieren un reordenamiento de las múltiples peticiones I/O, a diferencia de los discos duros normales.
Ventajas
Sirve las peticiones I/O con un menor número de ciclos de la CPU (¿mejora de la batería?).
Es el mejor para unidades flash.
Buen rendimiento en los sistemas db.
Inconvenientes
La reducción en el número de ciclos de la CPU es proporcional a la pérdida de rendimiento.

2) Deadline

 Cita:

El objetivo es minimizar la latencia de I/O o la necesidad de una petición. Esto se logra medianta una política de “todos contra todos”, para ser justos entre múltiples peticiones de I/O. Se utilizan 5 colas de espera para reordenar las solicitudes entrantes.
Ventajas
Se acerca bastante a un planificador a tiempo real.
Excelente en la reducción de latencia de peticiones I/O.
El mejor planificador para el acceso a bases de datos y consultas.
El requerimiento de “ancho de banda” de un proceso (el porcentaje de CPU que necesita) se puede calcular fácilmente.
Al igual que Noop, es un buen planificador para memorias flash.
Inconvenientes
Cuando el sistema está sobrecargado, la elección de procesos se puede volver impredecible

.


3) CFQ

 Cita:

Completely Fair Queuing (o dicho de manera cutre “cola completamente equitativa”) mantiene una cola de procesos estable, repartiendo el porcentaje necesitado de la CPU en partes iguales entre todas las peticiones I/O. El intervalo de tiempo asignado a cada cola depende de la prioridad del proceso primario.
Ventajas
Considerado el mejor ofreciendo un equilibrado rendimiento I/O.
El más fácil de configurar.
Excelente en sistemas multiprocesador.
El mejor rendimiento del sistema en bases de datos, después de Deadline.
Inconvenientes
Algunos usuarios reportan que el escáner de medios tarda bastante en completarse usando CFQ. Esto podría deberse a que la distribución del uso de la CPU se reparte equitativamente entre todas las operaciones I/O durante el arranque y no se conceden prioridades.
Jitter (el peor caso de retardo) puede llegar a ser alto debido a la cantidad de tareas que necesitan acceso al disco.

4) BFQ

 Cita:

En lugar de asignar intervalo de tiempo como CFQ, BFQ asigna como unos “presupuestos” estimativos. Garantiza el disco para el proceso activo hasta que el presupuesto expira. El presupuesto asignado a un proceso varía con el tiempo como una función de su comportamiento. (la traducción deja mucho que desear, si alguien la puede hacer mejor que me lo comente por PM).
Ventajas
Se cree que es muy bueno para la tasa de transferencia de datos vía USB.
Se cree que es el mejor scheduler para la grabación de videos de HD y video streaming (por el menor “jitter” en comparación con CFQ y los otros).
Es considerado un scheduler I/O muy preciso.
Alcanza alrededor de un 30% más de rendimiento que CFQ.
Inconvenientes
No es el mejor scheduler para hacer benchmarking.
El mayor “presupuesto” asignado a un proceso puede afectar a la experiencia de usuario y aumentar la latencia (retardos).

5) SIO

 Cita:

Es un scheduler I/O simple cuyo objetivo es mantener unos consumos mínimos y lograr un escaso restardo al atender solicitudes. Sio es una mezcla entre Noop y Deadline. No existe un reordenamiento de las peticiones.
Ventajas
Simple, muy seguro.
Minimiza la necesidad de atención de las solicitudes.
Inconvenientes
Velocidades lentas de lectura en memorias flash, en comparación con los otros schedulers.
La velocidad de las lecturas secuenciales en memorias flash tampoco es buena.

6)V(R)

 Cita:

A diferencia de los otros schedulers, las peticiones síncronas y asíncronas no se tratan de forma separada. La siguiente solicitud en ser atendida será la que más cercana esté a la última atendida.
Ventajas
Quizás es el mejor para benchmarking porque en el mejor de sus comportamientos el rendimiento es mejor.
Inconvenientes
Los resultados de las variaciones de rendimiento pueden ser que esté por debajo del promedio a veces.

Menos fiable y más inestable.


7) anticipatory

 Cita:

Con base en dos hechos
i) Disco busca son realmente lentos.
ii) Las operaciones de escritura puede suceder siempre, pero siempre hay algún proceso que está esperando operación de lectura.

Así que dar prioridad a las operaciones de lectura anticipada sobre escritura. Se anticipa a las operaciones de lectura sincrónica.

Ventajas:
Leer las peticiones de los procesos nunca se moría de hambre.
Tan bueno como para leer noop rendimiento en unidades flash.
Desventajas:
'Adivina obras' podría no ser siempre fiable.
Reducción del rendimiento de escritura en discos de alto rendimiento.

8) ROW

 Cita:

ROW significa "Lea WRITE", que es el principal peticiones despachan política de este algoritmo. El IO planificador ROW se desarrolló con los dispositivos móviles de necesidades en mente.En los dispositivos móviles nos volveremos tienen tanto hilos paralelos como en los escritorios. Por lo general es un solo hilo o como máximo 2 hilos de trabajo simultáneas de lectura y escritura. Favorecer las solicitudes de lectura más escribe disminuye la latencia de lectura mucho.

La idea principal de la política de planificación ROW es: Si hay solicitudes de lectura en la tubería - Envío ellos, pero no se mueren de hambre las solicitudes de escritura demasiado. se puede encontrar una pequeña comparación de fila para programadores existentes. La prueba que se ejecutó para estas mediciones se lee y se escribe paralelo.

[Nigthmare]

Deberian colgar una chincheta a esto

[slipknot30]

Muy buen hilo , si señor

 Cita: Originalmente Escrito por el.juaki

Deberian colgar una chincheta a esto

No hay presupuesto para chinchetas

[noulos_9]

Muchísimas gracias por el curro, muy buena la guía!

Chincheta!!!

[ozil78]

Gracias por el aporte, faltaría recordar el Westwood, es un gobernador que trae el kernel Franco no es así?

 Cita: Originalmente Escrito por ozil78

Gracias por el aporte, faltaría recordar el Westwood, es un gobernador que trae el kernel Franco no es así?

Es un scheduler, pero no encuentro info sobre el.

[3mundista]

Muchísimas gracias por el currazo que os habéis pegado

[aamtini]

 Cita: Originalmente Escrito por el.juaki

Deberian colgar una chincheta a esto

En efecto

[dnfuentes]

Muy buen tuto alexret!!