En Linux SCHED_FIFO y SCHED_RR

Escribo un daemon muy pequeño que debe seguir siendo receptivo incluso cuando un sistema está bajo una gran tensión. Estoy mirando las diferencias entre SCHED_FIFO y SCHED_RR con respecto a la programación, así como también tratando de determinar una prioridad sensata.En Linux SCHED_FIFO y SCHED_RR

¿Qué planificador sería apropiado para un daemon de monitoreo pequeño pero crítico, qué prioridad sería razonablemente segura? Todavía me estoy volviendo un poco confuso cuando trato de entender las diferencias entre los dos.

Mi programa se asigna a menos de 3k (y usa mlockall()), escribe unos 600 bytes a xenbus y luego duerme, pero es imposible para mí decir cuánto tiempo (en ms) se tardará realmente en escribir los datos .. ya que lo que está escrito depende de un archivo de configuración.

Gracias de antemano por cualquier sugerencia/explicación.

Fuente

2009-01-01 Tim Post

El infame programa pchdtvr, que captura señales de TV digitales, usa SCHED_FIFO para asegurarse de que los paquetes de TV se escriban en el disco pase lo que pase. Puede capturar 4 espectáculos a la vez mientras reproduce Doom en una computadora vieja.

El programa es infame porque fue lanzado bajo GPL y el autor tried to revoke the GPL retroactively. Este acto provocó una pequeña tormenta de fuego. De todos modos, puedes encontrar una versión reciente para estudiar al http://frequal.com/pmn/pchdtvr.html.

Fuente

2009-01-01 19:33:53

Es __realmente divertido ver a los desarrolladores elegir una licencia que no entendieron ... realmente triste, pero divertida. Voy a ir con FIFO, pero 'retroceder' cuando el programa puede y debe ceder y volver a la programación normal, o volver a RT cuando las cosas se ponen difíciles. Veré cómo va eso. –

@tinkertim: El furor en slashdot fue increíble. http://yro.slashdot.org/article.pl?no_d2=1&sid=08/01/26/0341210 –

no soy un experto para los esquemas de programación, pero echar un vistazo a

man sched_setscheduler

detalla cuál es la diferencia entre los diferentes algoritmos de planificación son, y proporcionar enlaces a otras funciones de programación. SCHED_FIFO realidad suena bastante peligroso, pero se describe como la programación más agresiva:

proceso Un SCHED_FIFO se prolongará hasta que es bloqueado por una solicitud de E/S, hasta que sea apropiado por un proceso de mayor prioridad, o hasta que llame sched_yield (2)

Tenga cuidado para no bloquear su sistema. Yo personalmente haría algunas pruebas empíricas para ver qué prioridad encaja mejor y cómo se comportan exactamente.

Fuente

2009-01-01 18:38:02

Gracias por la respuesta, miré las páginas del manual y varios documentos que aparecían en las búsquedas. Ahora estoy usando SCHED_FIFO sin problemas, pero me pregunto acerca de RR.No creo poder usar RR, ya que no tengo forma de saber si realmente puedo completar una escritura atómica en un solo segmento. –

Yo (podría) también llamar a sched_yield() una vez que el contenido de sysinfo() se convierta en agradable ... es decir, el sistema ya no está bajo estrés. Tal vez me quedo con FIFO pero escribo lógica para ir a RT solo cuando el sistema está (o estará pronto) estresado, luego retrocede cuando está tranquilo. –

hm, sí, creo que fifo parece razonable para esa tarea. –

Si todas sus otras tareas utilizan el programador estándar, no hace ninguna diferencia; SCHED_FIFO y SCHED_RR solo afectan la programación de estas tareas entre sí.

Así que en un sistema normal no hace la diferencia. FIFO es más fácil de entender, así que use eso, supongo.

Si tiene varias tareas de diferentes prioridades, solamente la más alta se llevará a cabo si están listos para ser ejecutado (y no sólo un núcleo CPU)

Fuente

2009-01-04 14:21:42 MarkR

SCHED_FIFO no pueda ser substituida (contexto ha cambiado a otro proceso) a menos que otro proceso de mayor prioridad aparezca en la cola de ejecución.

SCHED_RR puede ser reemplazado por un tiempo cuántico (retraso otorgado a un proceso para ejecutar).

Ambas son prioridades "en tiempo real" de los programadores basados en Linux.

Fuente

2011-02-23 00:58:59 Alex

Respuesta

Cuestiones relacionadas