Posterior a investigar en varios repositorios y páginas webs al final hallamos la resolución que te enseñaremos pronto.
Solución:
Hice un experimento para concretar esto, de la siguiente manera:
-
proceso1: prioridad RT = 40, afinidad de 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 de CPU = CPU 0. Este proceso imprime un mensaje en 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 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 process1 parece adelantarse a process2, sin permitir 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 reemplazado por process1.
Este experimento muestra que un mas grande El valor de prioridad RT en sched_setscheduler () tiene una prioridad más alta. Esto parece contradecir lo que Michael Foukarakis señaló en 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 () sucede 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
¡Guau! ¡Eso es confuso! Para resumir:
-
Con p-> prio, un valor menor reemplaza a un valor mayor.
-
Con p-> rt_priority, un valor mayor prevalece sobre un valor menor. Este es el conjunto de prioridades en tiempo real usando sched_setscheduler ().
Respuesta corta
99 será el ganador por prioridad en tiempo real.
PR es el nivel de prioridad (rango -100 a 40). 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 varía de -20 a 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, el normal unos y el tiempo real
Para los normales (y solo para aquellos), nice se aplica de la siguiente manera:
Bonito
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 agradable y PR es el nivel de prioridad. Entonces, como podemos ver, el -20 en realidad se asigna a 0, mientras que el 19 se asigna a 39.
De forma predeterminada, el valor agradable de un programa es de 0 bits; un usuario root puede almorzar programas con un valor agradable especificado mediante el siguiente comando:
nice -n ./myProgram
Tiempo real
Podríamos ir aún más lejos. La prioridad agradable se utiliza en realidad para los programas de usuario. Mientras que la prioridad general de UNIX / LINUX tiene un rango de 140 valores, el valor agradable permite que el proceso se asigne a la última parte del rango (de 100 a 139). Esta ecuación deja inalcanzables los valores de 0 a 99 que corresponderán a un nivel de PR negativo (de -100 a -1). Para poder acceder a esos valores, el proceso debe establecerse como "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 se pueden dividir 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 podría llamar a un proceso en tiempo real usando el siguiente comando (el ejemplo es cómo declarar una política SCHED_RR):
chrt --rr ./myProgram
Para obtener el valor de PR para 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 llamado con el número 99.
Es importante tener en cuenta que para los procesos en tiempo real, no se utiliza el valor agradable.
Para ver la "bondad" actual y el valor PR de un proceso, se puede ejecutar el siguiente comando:
top
Que muestra el siguiente resultado:
En la figura se muestran los valores de PR y NI. Es bueno notar 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 corresponde en realidad a un valor de PR de -100.
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: más bajos p->prio valor significa mayor prioridad.
Te mostramos reseñas y calificaciones
Si posees alguna sospecha y capacidad de acrecentar nuestro crónica eres capaz de añadir una crítica y con deseo lo interpretaremos.