La différence est que PR est une véritable priorité d'un processus à l'heure actuelle à l'intérieur du noyau et NI n'est qu'un indice pour le noyau de la priorité que le processus devrait avoir.
Dans la plupart des cas, la valeur PR peut être calculée par la formule suivante: PR = 20 + NI . Ainsi, le processus avec gentillesse 3 a la priorité 23 (20 + 3) et le processus avec gentillesse -7 a la priorité 13 (20 - 7). Vous pouvez vérifier le premier en exécutant la commande nice -n 3 top
. Cela montrera que le processus supérieur a NI 3 et PR 23 . Mais pour fonctionner nice -n -7 top
dans la plupart des systèmes Linux, vous devez disposer des privilèges root, car en réalité, la valeur PR inférieure est la priorité réelle la plus élevée. Ainsi, le processus avec PR 13 a une priorité plus élevée que les processus avec priorité standard PR 20. C'est pourquoi vous devez être root. Mais la valeur de gentillesse minimale autorisée pour les processus non root peut être configurée dans /etc/security/limits.conf .
Théoriquement, le noyau peut changer lui-même la valeur PR (mais pas NI ). Par exemple, il peut réduire la priorité d'un processus s'il consomme trop de CPU, ou il peut augmenter la priorité d'un processus si ce processus n'a pas eu la chance de s'exécuter pendant une longue période en raison d'autres processus de priorité plus élevée. Dans ces cas, la valeur PR sera modifiée par le noyau et NI restera la même, donc la formule "PR = 20 + NI" ne sera pas correcte. Ainsi, la valeur NI peut être interprétée comme une indication pour le noyau de la priorité que le processus devrait avoir, mais le noyau peut choisir lui-même la priorité réelle ( valeur PR ) en fonction de la situation. Mais généralement la formule"PR = 20 + NI" est correct.
Les règles exactes sur la façon dont le noyau change de priorité ne sont pas claires. Le manuel de setpriority (la fonction qui change la belle valeur) dit:
L'effet de la modification de la valeur de Nice peut varier en fonction de l'algorithme de planification de processus en vigueur.
Le manuel Pthread dit ce qui suit:
La priorité dynamique est basée sur la valeur nice (définie par nice (2), setpriority (2) ou sched_setattr (2)) et augmentée à chaque fois que le quantum du thread est prêt à s'exécuter, mais refusé de s'exécuter par le planificateur.
Il semble que la valeur PR corresponde à la priorité dynamique.
La plage de la valeur NI est -20..19 . Ainsi, la valeur PR peut avoir les valeurs de 0 (20 - 20) à 39 (20 + 19). Mais il n'est correct que pour les processus avec une politique de planification par défaut ( SHED_OTHER ). Il peut également y avoir des processus avec des politiques de planification dites "en temps réel" . Ces politiques sont SCHED_RR et SCHED_FIFO . Ces processus ont une valeur PR inférieure à 0. Vous pouvez le vérifier en exécutant la chrt -r 1 top
commande (vous devez être root). Le processus supérieur aura PR -2 . Vous pouvez même exécuter chrt -r 90 top
dans quel cas le hautprocessus aura PR -91 .
Il semble que pour les processus SCHED_RR la valeur PR peut être calculée par la formule:
PR = - 1 - sched_rr_priority .
Ainsi, un processus SCHED_RR a au moins PR -1, ce qui signifie que tout processus SCHED_RR a une priorité plus élevée que tout SCHED_OTHER . Cela correspond au manuel pthread:
SCHED_FIFO ne peut être utilisé qu'avec des priorités statiques supérieures à 0, ce qui signifie que lorsqu'un thread SCHED_FIFO devient exécutable, il prévient toujours immédiatement tout thread SCHED_OTHER, SCHED_BATCH ou SCHED_IDLE en cours d'exécution.
SCHED_RR est une simple amélioration de SCHED_FIFO. Tout ce qui est décrit ci-dessus pour SCHED_FIFO s'applique également à SCHED_RR,
La priorité des processus en temps réel est appelée priorité statique qui ne peut pas être modifiée par le noyau. Ainsi, les valeurs PR positives peuvent être traitées comme une priorité dynamique pour les processus non temps réel ( SCHED_OTHER , SCHED_BATCH ) et les valeurs PR négatives comme une priorité statique pour les processus temps réel ( SCHED_RR , SCHED_FIFO ).
J'ai aussi essayé de courir nice -n 10 chrt -r 50 top
(et chrt -r 50 nice -n 10 top
). La valeur NI était de 10, mais le PR était toujours de -51 . Il semble donc que la valeur NI n'affecte pas la priorité des processus SCHED_RR . Cela correspond au manuel setpriority :
Tout processus ou thread utilisant SCHED_FIFO ou SCHED_RR ne sera pas affecté par un appel à setpriority (). Ce n'est pas considéré comme une erreur. Un processus qui revient ensuite à SCHED_OTHER n'a pas besoin que sa priorité soit affectée par un tel appel setpriority ().
Une note amusante. Si vous exécutez chrt -r 99 top
, vous verrez la valeur RT au lieu d'un nombre dans la colonne PR .
UTILISATEUR PID PR NI VIRT RES SHR S% CPU% MEM TIME + COMMAND
28489 racine RT 0 2852 1200896 R 0 0,1 0: 00,01 haut
Je ne pense pas que cela signifie que le processus est maintenant spécial. Je pense que cela signifie que le haut n'imprime tout simplement pas -100 car il faudrait 4 caractères pour imprimer.
Vous pouvez également utiliser htop au lieu de top dans tous les exemples, ce qui peut être plus pratique. ps -l
peut également être utilisé, mais le point de base qui sépare les priorités en temps réel et non en temps réel n'est pas 0, mais 60, donc nice -n -20 ps -l
imprimera
FS UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
4 R 0 28983 28804 0 60-20-1176 - pts / 6 00:00:00 ps