Cómo aumentar la prioridad de subprocesos en pthreads?

Question

Estoy usando pthread en Linux. Me gustaría aumentar la prioridad del hilo estableciendo los parámetros sched_param.priority. Sin embargo, no pude encontrar mucha información de la red con respecto al rango de la prioridad del hilo que pude establecer, o sobre la descripción de la prioridad del hilo.

Además, me gustaría saber acerca de la prioridad relativa de subprocesos, ya que no me gustaría configurar la prioridad de subproceso demasiado alta y que el sistema operativo se detenga. ¿Podría alguien ayudarme con esto?

Answer 1

La política de programación de Linux predeterminada es SCHED_OTHER, que no tienen prioridad pero un nivel nice para ajustar dentro de la política.

Vas a tener que cambiar a otra política programación usando la función pthread_setschedparam (véase también man sched_setscheduler)

políticas de planificación 'normal': (de sched_setscheduler(2))

SCHED_OTHER the standard round-robin time-sharing policy; 
    SCHED_BATCH for "batch" style execution of processes; and 
    SCHED_IDLE for running very low priority background jobs. 

políticas de planificación en tiempo real :

SCHED_FIFO a first-in, first-out policy; and 
    SCHED_RR  a round-robin policy. 

En su caso, puede usar SCHED_BATCH ya que esto no requiere privilegios de root.

Advertencia: uso incorrecto de las políticas de programación en tiempo real puede bloquear su sistema. Es por eso que necesita privilegios de root para hacer este tipo de operación.

Solo para asegurarse de lo que su máquina es capaz de hacer, puede usar la herramienta chrt del paquete util-linux.
A modo de ejemplo:

$ chrt -m 
SCHED_OTHER min/max priority : 0/0 
SCHED_FIFO min/max priority  : 1/99 
SCHED_RR min/max priority  : 1/99 
SCHED_BATCH min/max priority : 0/0 
SCHED_IDLE min/max priority  : 0/0 

Una manera de residuos menos tiempo (que a menudo utilizo):

alias batchmake='time chrt --batch 0 make --silent' 

Durante su estancia con los privilegios del usuario, esto impulsa la make en un 15% (en mi caso).

Editar: introducir nice, SCHED_BATCH, SCHED_IDLE y chrt herramienta. Para precisión ! :)

Answer 2

POSIX define una consulta, por lo que puede solicitar al sistema operativo el rango válido de prioridades.

int sched_get_priority_max(int policy);

int sched_get_priority_min(int policy);

no esperamos que eleva la prioridad para sofocar la máquina. De hecho, no espere que haga nada a menos que ya esté usando el 100% de los ciclos de la CPU. No se sorprenda si la consulta le dice que no hay prioridad más alta que la predeterminada.

Answer 3

La respuesta actual de levif (recomendando SCHED_BATCH) no es correcta para la implementación actual de subprocesos NPTL en Linux (puede verificar qué implementación tiene su kernel ejecutando 'getconf GNU_LIBPTHREAD_VERSION').

En el kernel de hoy, solo las políticas de programación en tiempo real permiten establecer sched_priority: siempre es 0 para las políticas que no son RT (SCHED_OTHER, SCHED_BATCH y SCHED_IDLE). Su única opción para las políticas que no son RT es establecer valores 'agradables', p. por setpriority(). Sin embargo, no hay buenas especificaciones del comportamiento exacto que esperar estableciendo 'bueno', y al menos en teoría podría variar desde la versión del núcleo hasta la versión del kernel. Para los kernels actuales de Linux, "nice" tiene un efecto muy fuerte similar a la prioridad, por lo que puede usarlo de manera bastante intercambiable. Para aumentar la frecuencia con la que está programado el hilo, desea menor su valor 'bueno'. Esto requiere la capacidad CAP_SYS_NICE (típicamente raíz, aunque no necesariamente, vea http://man7.org/linux/man-pages/man7/capabilities.7.html y http://man7.org/linux/man-pages/man3/cap_set_proc.3.html).

De hecho SCHED_OTHER está diseñado para el caso opuesta a lo que el interlocutor solicitado: está diseñado para trabajos de larga ejecutan intensivo de la CPU, que puede vivir con menor prioridad. Le dice al programador que penalice levemente la prioridad de activación de los subprocesos.

También para responder a uno de los comentarios anteriores (todavía no tengo suficiente reputación para comentar en respuesta - algunos votos favorables para esta respuesta podrían ayudar :)). Sí, la mala noticia es que la especificación POSIX.1 dice que 'bueno' afecta a los procesos, no a los hilos individuales. La buena noticia es que las implementaciones de subprocesos de Linux (tanto NPTL como los subprocesos de Linux originales) rompen la especificación y le permiten afectar subprocesos individuales. Encuentro divertido que esto a menudo se menciona en la sección "ERRORES" de las páginas man. Yo diría que el error estaba en la especificación POSIX.1, que debería haber permitido este comportamiento, no en las implementaciones que se vieron obligadas a proporcionarlo a pesar de la especificación y lo hicieron a sabiendas y deliberadamente. En otras palabras, no es un error.

mayoría de esto es detallado en la (7) página de manual sched (que por alguna razón no se entrega en mi sistema Fedora 20): http://man7.org/linux/man-pages/man7/sched.7.html

Si realmente quería que afectan sched_priority usted podría mirar a la Políticas en tiempo real como SCHED_RR).