c++ - pthread_create - Cómo aumentar la prioridad de subprocesos en pthreads?

pthreads php

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 sobre la prioridad relativa de subprocesos, ya que no me gustaría establecer la prioridad de subproceso demasiado alta y el sistema operativo se detiene. ¿Podría alguien ayudarme con esto?

Answer 1

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

Tendrá que cambiar a otra política de programación mediante la función pthread_setschedparam (consulte también man sched_setscheduler )

Políticas de programación ''Normal'': (desde 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 programación en tiempo real:

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

En su caso, quizás pueda usar SCHED_BATCH ya que esto no requiere privilegios de SCHED_BATCH .

Advertencia: el 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 estar seguro de lo que su máquina es capaz de hacer, puede usar la herramienta chrt del paquete util-linux .
Como 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 forma de perder menos tiempo (que a menudo uso):

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

Mientras se mantiene con los privilegios de usuario, esto impulsa la make en un 15% (en mi caso).

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

Answer 2

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", por ejemplo, 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 reducir el 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_BATCH está diseñado para el caso contrario al que solicitó el consultante: está diseñado para trabajos intensivos en CPU y de larga ejecución, que pueden 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.

La mayoría de esto se detalla en la página man de sched (7) (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 desea afectar a sched_priority, puede consultar las políticas de tiempo real, como SCHED_RR).

Answer 3

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

int sched_get_priority_max(int policy);

int sched_get_priority_min(int policy);

No espere prioridad elevada para estrangular 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.