Diferencia entre valor agradable y prioridad en la salida superior


11

arriba , por defecto, enumera ambas columnas. Tengo curiosidad por saber cuál es la diferencia. Revisé las páginas del manual y no puedo entenderlo:

Prioridad:

   h: PR  --  Priority
      The priority of the task.

Buen valor:

   i: NI  --  Nice value
      The nice value of the task.  A negative nice value means higher  priority,
      whereas  a  positive  nice value means lower priority.  Zero in this field
      simply means priority will not be adjusted in determining  a  task’s  dis-
      patchability.

Entiendo que el valor de Nice está relacionado con la cola del programador de CPU del Kernel; entonces, ¿qué indica Prioridad ? ¿Algo relacionado con E / S tal vez?

Respuestas:


8

El buen valor es un mecanismo "global", mientras que la prioridad es relevante para el conmutador de tareas en este momento .


¿Qué quieres decir con conmutador de tareas?
Belmin Fernández

1
El conmutador de tareas (propiamente llamado "planificador") es un poco de código dentro del núcleo que decide qué tarea se ejecutará a continuación.
Ignacio Vazquez-Abrams

25

La diferencia es que PR es una prioridad real de un proceso en este momento dentro del núcleo y NI es solo una pista para el núcleo sobre la prioridad que debería tener el proceso.

En la mayoría de los casos, el valor de PR puede calcularse mediante la siguiente fórmula: PR = 20 + NI . Por lo tanto, el proceso con amabilidad 3 tiene la prioridad 23 (20 + 3) y el proceso con amabilidad -7 tiene la prioridad 13 (20-7). Puede verificar el primero ejecutando el comando nice -n 3 top. Mostrará que el proceso superior tiene NI 3 y PR 23 . Pero para ejecutarse nice -n -7 topen la mayoría de los sistemas Linux necesita tener privilegios de root porque en realidad el valor PR más bajo es la prioridad real más alta. Por lo tanto, el proceso con PR 13 tiene mayor prioridad que los procesos con prioridad estándar PR 20. Es por eso que necesitas ser root. Pero el valor de bondad mínimo permitido para el proceso no root se puede configurar en /etc/security/limits.conf .

Teóricamente, el núcleo puede cambiar el valor de PR (pero no NI ) por sí mismo. Por ejemplo, puede reducir la prioridad de un proceso si consume demasiada CPU, o puede aumentar la prioridad de un proceso si ese proceso no tuvo oportunidad de ejecutarse durante mucho tiempo debido a otros procesos de mayor prioridad. En estos casos, el valor de PR será cambiado por el núcleo y NI seguirá siendo el mismo, por lo que la fórmula "PR = 20 + NI" no será correcta. Por lo tanto, el valor de NI puede interpretarse como una pista para el núcleo sobre la prioridad que debe tener el proceso, pero el núcleo puede elegir la prioridad real ( valor de PR ) por sí mismo dependiendo de la situación. Pero por lo general la fórmula"PR = 20 + NI" es correcto.

Las reglas exactas de cómo el núcleo cambia la prioridad no están claras. El manual setpriority (la función que cambia un buen valor) dice:

El efecto de cambiar el valor agradable puede variar según el algoritmo de programación de procesos vigente.

El manual de Pthread dice lo siguiente:

La prioridad dinámica se basa en el valor agradable (establecido por nice (2), setpriority (2) o sched_setattr (2)) y se incrementa para cada cantidad de tiempo que el subproceso está listo para ejecutarse, pero el planificador lo niega.

Parece que el valor PR corresponde a la prioridad dinámica.

El rango del valor de NI es -20..19 . Por lo tanto, el valor PR puede tener los valores de 0 (20-20) a 39 (20 + 19). Pero es correcto solo para los procesos con política de programación predeterminada ( SHED_OTHER ). También puede haber procesos con las llamadas políticas de programación "en tiempo real" . Estas políticas son SCHED_RR y SCHED_FIFO . Dichos procesos tienen un valor PR inferior a 0. Puede verificar esto ejecutando el chrt -r 1 topcomando (debe ser root). El proceso superior tendrá PR -2 . Incluso puedes correr chrt -r 90 topen cuyo caso la parte superiorEl proceso tendrá PR -91 .

Parece que para los procesos SCHED_RR el valor de PR puede calcularse mediante la fórmula:

PR = - 1 - sched_rr_priority .

Por lo tanto, un proceso SCHED_RR tiene al menos PR -1, lo que significa que cualquier proceso SCHED_RR tiene mayor prioridad que cualquier SCHED_OTHER . Esto corresponde al manual de pthread:

SCHED_FIFO solo se puede usar con prioridades estáticas superiores a 0, lo que significa que cuando un subproceso SCHED_FIFO se vuelve ejecutable, siempre prevalecerá inmediatamente sobre cualquier subproceso SCHED_OTHER, SCHED_BATCH o SCHED_IDLE actualmente en ejecución.

SCHED_RR es una mejora simple de SCHED_FIFO. Todo lo descrito anteriormente para SCHED_FIFO también se aplica a SCHED_RR,

La prioridad de los procesos en tiempo real se conoce como prioridad estática que el núcleo no puede cambiar. Por lo tanto, los valores PR positivos pueden tratarse como prioridad dinámica para procesos que no son en tiempo real ( SCHED_OTHER , SCHED_BATCH ) y el valor PR negativo como prioridad estática para procesos en tiempo real ( SCHED_RR , SCHED_FIFO ).

También intenté correr nice -n 10 chrt -r 50 top(y chrt -r 50 nice -n 10 top). El valor de NI fue 10, pero el PR aún fue -51 . Entonces parece que el valor de NI no afecta la prioridad de los procesos SCHED_RR . Esto corresponde al manual setpriority :

Cualquier proceso o subproceso que use SCHED_FIFO o SCHED_RR no se verá afectado por una llamada a setpriority (). Esto no se considera un error. Un proceso que posteriormente vuelve a SCHED_OTHER no necesita tener su prioridad afectada por dicha llamada setpriority ().

Una nota graciosa Si ejecuta chrt -r 99 top, verá el valor RT en lugar de un número en la columna PR .

  PID USUARIO PR NI VIRT RES SHR S% CPU% MEM TIME + COMMAND
28489 raíz RT 0 2852 1200 896 R 0 0.1 0: 00.01 arriba

No creo que esto signifique que el proceso ahora sea especial. Creo que esto significa que la parte superior simplemente no imprime -100 porque tomaría 4 caracteres para imprimir.

También puede usar htop en lugar de top en todos los ejemplos que pueden ser más convenientes. ps -ltambién se puede usar, pero el punto base que separa las prioridades en tiempo real y no en tiempo real no es 0, sino 60, por lo que nice -n -20 ps -lse imprimirá

FS UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIEMPO CMD
4 R 0 28983 28804 0 60-20-1176 - pts / 6 00:00:00 ps

Por extraño que parezca, si ejecuto 5 bucles infinitos (int main {while (1);}) en un i3 hyperthreaded de 2 núcleos, sus prioridades permanecen constantes. Esto en las pruebas de Debian Sid.
Vorac

1
@BelminFernandez Creo que será justo que esta respuesta sea "aceptada".
z0lupka

1

Respuesta corta

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 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, los normales y el tiempo real. Para los normales (y solo para esos), nice se aplica de la siguiente manera:

agradable

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. Como podemos ver, el -20 en realidad se asigna a 0, mientras que el 19 se asigna a 39.

Por defecto, el valor agradable de un programa es de 0 bits, es posible que un usuario root almuerce programas con un valor agradable especificado utilizando el siguiente comando:

nice -n <nice_value> ./myProgram 

Tiempo real

Podríamos ir aún más lejos. La buena prioridad se usa realmente 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, lo que corresponderá a un nivel PR negativo (de -100 a -1). Para poder acceder a esos valores, el proceso debe establecerse como "en tiempo real".

Hay 5 políticas de programación en un entorno LINUX que se pueden mostrar con el siguiente comando:

chrt -m 

Lo 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 utilizando 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 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 "simpatía" actual y el valor de PR de un proceso, se puede ejecutar el siguiente comando:

top

Es bueno tener en cuenta que los procesos con valor PR -51, por ejemplo, corresponden a un valor en tiempo real. También hay algunos procesos cuyo valor PR se indica como "rt". Este valor corresponde en realidad a un valor PR de -100.

(PD: Hubiera publicado una imagen que muestra el mejor resultado, pero no tengo la reputación para hacerlo)

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.