Qué prioridad en tiempo real es la prioridad más alta en Linux
En el rango de prioridad de proceso en tiempo real de Linux del 1 al 99, no me queda claro cuál es la prioridad más alta, 1 o 99.
La sección 7.2.2 de "Comprensión del núcleo Linux" (O'Reilly) dice que 1 es la prioridad más alta, lo que tiene sentido considerando que los procesos normales tienen prioridades estáticas de 100 a 139, siendo 100 la prioridad más alta:
" Cada proceso en tiempo real está asociado con una prioridad en tiempo real, que es un valor que va desde 1 (mayor prioridad) 99 (prioridad más baja). "
Por otro lado, la página man de sched_setscheduler (RHEL 6.1) afirma que 99 es la más alta:
" Procesos programados bajo una de las políticas en tiempo real (SCHED_FIFO, SCHED_RR) tener un valor sched_priority en el rango 1 (bajo) a 99 (alto)."
¿Cuál es la prioridad más alta en tiempo real?
6 answers
Hice un experimento para clavar esto, de la siguiente manera:
Process1: prioridad RT = 40, afinidad CPU = CPU 0. Este proceso "gira" durante 10 segundos, por lo que no permitirá que ningún proceso de menor prioridad se ejecute en la CPU 0.
Process2: prioridad RT = 39, afinidad CPU = CPU 0. Este proceso imprime un mensaje a stdout cada 0.5 segundos, durmiendo en el medio. Imprime el tiempo transcurrido con cada mensaje.
Estoy ejecutando un kernel 2.6.33 con el PREEMPT_RT parche.
Para ejecutar el experimento, corro process2 en una ventana (como root) y luego inicio process1 (como root) en otra ventana. El resultado es que process1 parece adelantarse a process2, no permitiendo que se ejecute durante 10 segundos completos.
En un segundo experimento, cambio la prioridad RT de process2 a 41. En este caso, process2 es no invalidada por process1.
Este experimento muestra que un mayor valor de prioridad RT en sched_setscheduler() tiene una prioridad más alta. Esto parece contradecir lo que Michael Foukarakis señaló de sched.h, pero en realidad no lo hace. In sched.c en la fuente del núcleo, tenemos:
static void
__setscheduler(struct rq *rq, struct task_struct *p, int policy, int prio)
{
BUG_ON(p->se.on_rq);
p->policy = policy;
p->rt_priority = prio;
p->normal_prio = normal_prio(p);
/* we are holding p->pi_lock already */
p->prio = rt_mutex_getprio(p);
if (rt_prio(p->prio))
p->sched_class = &rt_sched_class;
else
p->sched_class = &fair_sched_class;
set_load_weight(p);
}
Rt_mutex_getprio (p) hace lo siguiente:
return task->normal_prio;
Mientras que normal_prio () pasa a hacer lo siguiente:
prio = MAX_RT_PRIO-1 - p->rt_priority; /* <===== notice! */
...
return prio;
En otras palabras, tenemos (mi propia interpretación):
p->prio = p->normal_prio = MAX_RT_PRIO - 1 - p->rt_priority
Wow! Que es confuso! Para resumir:
Con p - >prio, un valor más pequeño prevalece sobre un valor más grande valor.
Con p - >rt_priority, un valor más grande precede a un valor más pequeño. Este es el conjunto de prioridades en tiempo real usando sched_setscheduler ().
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
2012-02-14 22:25:06
Este comentario en sched.h es bastante definitivo:
/*
* Priority of a process goes from 0..MAX_PRIO-1, valid RT
* priority is 0..MAX_RT_PRIO-1, and SCHED_NORMAL/SCHED_BATCH
* tasks are in the range MAX_RT_PRIO..MAX_PRIO-1. Priority
* values are inverted: lower p->prio value means higher priority.
*
* The MAX_USER_RT_PRIO value allows the actual maximum
* RT priority to be separate from the value exported to
* user-space. This allows kernel threads to set their
* priority to a value higher than any user task. Note:
* MAX_RT_PRIO must not be smaller than MAX_USER_RT_PRIO.
*/
Note esta parte:
Los valores de prioridad se invierten: menor p->prio valor significa mayor prioridad.
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
2012-02-08 07:59:03
Para determinar la prioridad más alta en tiempo real que puede establecer programáticamente, use la función sched_get_priority_max.
En Linux 2.6.32 una llamada a sched_get_priority_max(SCHED_FIFO) devuelve 99.
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
2012-02-08 06:37:02
Su suposición de que los procesos normales tienen prioridades estáticas de 100 a 139 es volátil en el mejor de los casos e inválida en el peor. Lo que quiero decir es que: set_scheduler solo permite que sched_priority sea 0 (lo que indica el planificador de prioridades dinámicas) con SCHED_OTHER / SCHED_BATCH y SCHED_IDLE (true a partir de 2.6.16).
Las prioridades estáticas programáticas son 1-99 solo para SCHED_RR y SCHED_FIFO
Ahora puede ver las prioridades de 100-139 siendo usadas internamente por un programador dinámico howeve, r lo que el kernel hace internamente para administrar prioridades dinámicas (incluyendo voltear el significado de prioridad alta vs.baja para hacer la comparación o clasificación más fácil) debería ser opaco para el espacio de usuario.
Recuerde que en SCHED_OTHER está principalmente rellenando los procesos en la misma cola de prioridad.
La idea es hacer que el kernel sea más fácil de depurar y evitar errores fuera de límite.
Así que la razón para cambiar el significado podría ser que como desarrollador del kernel no quieres usar matemáticas como 139-idx (solo en caso de que idx > 139)... es mejor hacer matemáticas con idx-100 y revertir el concepto de baja vs alta porque idx
También un efecto secundario es que la amabilidad se vuelve más fácil de tratar. 100 - 100 nice == 0; 101-100 nice == 1; etc. es más fácil. Se colapsa a números negativos muy bien también (NADA que ver con prioridades estáticas) 99-100 nice == -1 ...
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
2012-01-16 23:32:44
- Absolutamente, la prioridad en tiempo real es aplicable a las políticas RT FIFO y RR que varían de 0 a 99.
-
Tenemos el 40 como un recuento de la prioridad de proceso en tiempo no real para BATCH, OTRAS políticas que varían de 0-39 no de 100 a 139. Esto, se puede observar mirando cualquier proceso en el sistema que no es un proceso en tiempo real. Tendrá un PR de 20 y la amabilidad de 0 por defecto. Si disminuye la amabilidad de un proceso (generalmente, baja o negativa la número menor la amabilidad, más hambre el proceso), decir de 0 a -1, usted 'll observar que la prioridad caerá a 19 de 20. Esto simplemente dice que, si usted hace un proceso más hambre o le gustaría obtener un poco más de atención por la disminución del valor de la amabilidad del PID usted 'll obtener disminución en la prioridad también, por lo tanto bajar el número de PRIORIDAD MÁS ALTA la PRIORIDAD.
Example: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2079 admin 10 -10 280m 31m 4032 S 9.6 0.0 21183:05 mgmtd [[email protected] ~]# renice -n -11 2079 2079: old priority -10, new priority -11 [[email protected] ~]# top -b | grep mgmtd 2079 admin 9 -11 280m 31m 4032 S 0.0 0.0 21183:05 mgmtd ^C
Espero que este ejemplo práctico aclare las dudas y pueda ayudar a fijar las palabras en la fuente incorrecta, si cualquier.
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
2016-12-01 10:18:59
Respuesta Corta
99 será el ganador de la prioridad en tiempo real.
PR es el nivel de prioridad. Cuanto menor sea el PR, mayor será la prioridad del proceso.
PR se calcula de la siguiente manera:
- para procesos normales: PR = 20-NI (NI es agradable y oscila entre -20 y 19)
- para procesos en tiempo real: PR = - 1-real_time_priority (real_time_priority varía de 1 a 99)
Respuesta Larga
Hay 2 tipos de procesos, los normales y los en tiempo real Para los normales (y solo para aquellos), nice se aplica de la siguiente manera:
Nice
La escala de "amabilidad" va de -20 a 19, mientras que -20 es la prioridad más alta y 19 la prioridad más baja. El nivel de prioridad se calcula de la siguiente manera:
PR = 20 + NI
Donde NI es el nivel nice y PR es el nivel de prioridad. Así como podemos ver, el -20 realmente mapas a 0, mientras que el 19 mapas a 39.
De forma predeterminada, un valor nice del programa es 0 bit es posible que un usuario root almuerce programas con un valor nice especificado mediante el siguiente comando:
nice -n <nice_value> ./myProgram
En tiempo real
Podríamos ir aún más lejos. La prioridad nice se utiliza en realidad para los programas de usuario. Mientras que la prioridad general de UNIX/LINUX tiene un rango de 140 valores, nice value permite al proceso mapear la última parte del rango (de 100 a 139). Esta ecuación deja los valores de 0 a 99 inalcanzable que corresponderá a un nivel de PR negativo (de -100 a -1). Para poder acceder a esos valores, el proceso debe declararse en"tiempo real".
Hay 5 políticas de programación en un entorno LINUX que se pueden mostrar con el siguiente comando:
chrt -m
Que mostrará la siguiente lista:
1. SCHED_OTHER the standard round-robin time-sharing policy
2. SCHED_BATCH for "batch" style execution of processes
3. SCHED_IDLE for running very low priority background jobs.
4. SCHED_FIFO a first-in, first-out policy
5. SCHED_RR a round-robin policy
Los procesos de programación podrían dividirse en 2 grupos, las políticas de programación normales (1 a 3) y las políticas de programación en tiempo real (4 y 5). Los procesos en tiempo real siempre tendrán prioridad sobre los procesos normales. Se puede llamar a un proceso en tiempo real usando el siguiente comando (El ejemplo es cómo declarar una política SCHED_RR):
chrt --rr <priority between 1-99> ./myProgram
Para obtener el valor PR de un proceso en tiempo real se aplica la siguiente ecuación:
PR = -1-rt_prior
Donde rt_prior corresponde a la prioridad entre 1 y 99. Por esa razón, el proceso que tendrá mayor prioridad sobre otros procesos será el que llamó con el número 99.
Es importante tener en cuenta que para los procesos en tiempo real, el valor nice no se utiliza.
Para ver la "amabilidad" actual y el valor PR de un proceso, se puede ejecutar el siguiente comando:
top
Que muestra la siguiente salida:
En la figura se muestran los valores PR y NI. Es bueno tener en cuenta el proceso con valor PR -51 que corresponde a un valor en tiempo real. También hay algunos procesos cuyo valor de PR se indica como "rt". Este valor en realidad corresponde a un valor PR de -100.
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
2018-09-26 09:55:16