¿Cómo aumentar la prioridad de hilo en pthreads?
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 sobre el 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 del subproceso, ya que no quiero establecer la prioridad del subproceso para que sea demasiado alta y el sistema operativo se detenga. ¿Alguien podría ayudarme con esto?
3 answers
La política de programación de Linux predeterminada es SCHED_OTHER, que no tiene opción de prioridad sino un nivel nice para ajustar dentro de la política.
Tendrá que cambiar a otra política de programación utilizando function pthread_setschedparam (véase también man sched_setscheduler)
Políticas de programación'normales': (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 programación en tiempo real:
SCHED_FIFO a first-in, first-out policy; and
SCHED_RR a round-robin policy.
En su caso, tal vez pueda usar SCHED_BATCH ya que esto no requiere privilegios de root.
Advertencia: uso incorrecto de las políticas de programación en tiempo real pueden 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 utilizar chrt herramienta de
util-linux paquete.
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 manera de perder menos tiempo (que uso a menudo):
alias batchmake='time chrt --batch 0 make --silent'
Mientras se mantiene con privilegios de usuario, esto impulsa el make en un 15% (en mi caso).
Edit: introducción nice, SCHED_BATCH, SCHED_IDLE y chrt herramienta. ¡Por la precisión ! :)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-09-15 19:41:41
La respuesta actual de levif (recomendando SCHED_BATCH) no es correcta para la implementación actual del subproceso NPTL en Linux (puede comprobar qué implementación tiene su núcleo ejecutando 'getconf GNU_LIBPTHREAD_VERSION').
En el núcleo actual solo las políticas de Programación en Tiempo Real permiten establecer sched_priority - siempre es 0 para las políticas que no son de 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 al establecer 'nice', y al menos en teoría podría variar de una versión del núcleo a otra. Para los núcleos de Linux actuales, 'nice' tiene un efecto muy fuerte similar a priority, por lo que puede usarlo prácticamente indistintamente. Para aumentar la frecuencia con la que se programa tu hilo, quieres bajar tu valor 'agradable'. Esto requiere la capacidad CAP_SYS_NICE (normalmente root, 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 opuesto caso a lo que el interrogador pidió: está diseñado para trabajos de larga duración y uso intensivo de CPU, que pueden vivir con menor prioridad. Le dice al programador que penalice ligeramente la prioridad de activación de los hilos.
También para responder a uno de los comentarios anteriores (todavía no tengo reputación suficiente para comentar en respuesta - algunos votos positivos para esta respuesta ayudaría :) ). Si la mala noticia es que el POSIX.1 la especificación dice que 'nice' 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 originales de Linux) rompen la especificación y permiten que afecte a subprocesos individuales. Me parece divertido que esto se llame a menudo en la sección" ERRORES " de las páginas de manual. Yo diría que el micrófono estaba en el POSIX.1 especificación, 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 parte 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 sched_priority, podría mirar el Tiempo Real políticas como SCHED_RR).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-11-24 20:28:38
POSIX define una consulta, por lo que puede pedir al sistema operativo el rango válido de prioridades.
int sched_get_priority_max(int policy);
int sched_get_priority_min(int policy);
No esperes que la prioridad elevada ahogue la máquina. De hecho, no esperes que haga nada a menos que ya estés usando el 100% de los ciclos de CPU. No se sorprenda si la consulta le dice que no hay prioridad mayor que la predeterminada.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-09-06 05:57:47