usuario - Qué prioridad en tiempo real es la prioridad más alta en Linux
ubuntu nice (5)
- Absolutamente, la prioridad en tiempo real es aplicable a las políticas RT FIFO y RR que varía de 0 a 99.
Tenemos 40 como un recuento de la prioridad del proceso en tiempo no real para BATCH, OTRAS políticas que varía de 0 a 39, no de 100 a 139. Esto se puede observar al observar cualquier proceso en el sistema que no sea en tiempo real. proceso. Tendrá un PR de 20 y una Nceness de 0 por defecto. Si disminuye la amabilidad de un proceso (por lo general, más bajo o negativo cuanto menor sea la amabilidad, más hambre tenga el proceso), digamos de 0 a -1, observará que la prioridad bajará a 19 de 20. Esto simplemente le dice que si haces que un proceso tenga más hambre o si deseas obtener un poco más de atención al disminuir el valor de amabilidad del PID, también obtendrás una disminución en la prioridad, por lo tanto, reducirás el número de PRIORIDAD MÁS ALTO 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 corregir las palabras en una fuente incorrecta, en su caso.
En el rango de prioridades de proceso en tiempo real de Linux de 1 a 99, no está claro para mí cuál es la prioridad más alta, 1 o 99.
La sección 7.2.2 de "Understanding the Linux Kernel" (O''Reilly) dice que 1 es la prioridad más alta, lo cual 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 de 1 (prioridad más alta) a 99 (prioridad más baja)".
Por otro lado, la página man sched_setscheduler (RHEL 6.1) afirma que 99 es el más alto:
"Los procesos programados en una de las políticas en tiempo real (SCHED_FIFO, SCHED_RR) tienen un valor sched_priority en el rango de 1 (bajo) a 99 (alto)".
¿Cuál es la prioridad más alta en tiempo real?
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.
*/
Tenga en cuenta esta parte:
Los valores de prioridad están invertidos: un valor de p->prio bajo significa una prioridad más alta .
Hice un experimento para aclarar esto, de la siguiente manera:
proceso1: 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.
proceso2: Prioridad RT = 39, afinidad CPU = CPU 0. Este proceso imprime un mensaje a la salida estándar cada 0.5 segundos, durmiendo en el medio. Imprime el tiempo transcurrido con cada mensaje.
Estoy ejecutando un kernel 2.6.33 con el parche PREEMPT_RT.
Para ejecutar el experimento, ejecuto process2 en una ventana (como root) y luego inicio process1 (como root) en otra ventana. El resultado es que el proceso 1 se adelanta al proceso2, lo que no permite que se ejecute durante 10 segundos completos.
En un segundo experimento, cambio la prioridad RT de process2 a 41. En este caso, proceso1 no es reemplazado 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 es así. En sched.c en la fuente del kernel, 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 () hace 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
¡Guauu! Eso es confuso! Para resumir:
Con p-> prio, un valor más pequeño reemplaza a un valor mayor.
Con p-> rt_priority, un valor mayor reemplaza un valor más pequeño. Esta es la prioridad en tiempo real establecida usando sched_setscheduler ().
Para determinar la prioridad más alta en tiempo real que puede establecer mediante programación, haga uso de la función sched_get_priority_max.
En Linux 2.6.32 una llamada a sched_get_priority_max (SCHED_FIFO) devuelve 99.
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 y no válida en el peor de los casos. Lo que quiero decir es que: set_scheduler solo permite que sched_priority sea 0 (lo que indica el planificador de prioridad dinámica) con SCHED_OTHER / SCHED_BATCH y SCHED_IDLE (true a partir de 2.6.16).
Prioridades programáticamente estáticas son 1-99 solo para SCHED_RR y SCHED_FIFO
Ahora puede ver que las prioridades de 100-139 sean utilizadas internamente por un planificador dinámico; sin embargo, lo que el kernel hace internamente para administrar las prioridades dinámicas (incluyendo voltear el significado de alta vs. baja prioridad para facilitar la comparación o clasificación) debería ser opaco al espacio de usuario.
Recuerde que en SCHED_OTHER usted está rellenando los procesos en la misma cola de prioridad.
La idea es hacer que kernel sea más fácil de depurar y evitar errores tontos fuera de límite.
Entonces, la razón para cambiar el significado podría ser que, como desarrollador de kernel, no quiere usar matemática como 139-idx (solo en el caso de idx> 139) ... es mejor hacer matemática con idx-100 y revertir el concepto de bajo vs. alto porque idx <100 es bien entendido.
También un efecto secundario es que la amabilidad se vuelve más fácil de tratar. 100 - 100 <=> agradable == 0; 101-100 <=> agradable == 1; etc. es más fácil. También se colapsa en números negativos (NO HAY NADA que ver con las prioridades estáticas) 99 - 100 <=> nice == -1 ...