La différence est que PR est une véritable priorité d'un processus pour le moment à l'intérieur du noyau et de NI n'est qu'un indice pour le noyau de la priorité que le processus devrait avoir.
Dans la plupart des cas, PR la valeur 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 top le processus a NI 3 et PR 23 . Mais pour exécuter nice -n -7 top dans la plupart des systèmes Linux, vous devez disposer des privilèges root car en réalité le PR inférieur la valeur 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 une 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 PR valeur (mais pas NI ) par lui-même. 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 à cause d'autres processus de priorité plus élevée. Dans ces cas, le PR la valeur sera modifiée par le noyau et NI restera le même, donc la formule "PR =20 + NI" ne sera pas correct. Alors le NI la valeur peut être interprétée comme un indice pour le noyau de la priorité que le processus devrait avoir, mais le noyau peut choisir la priorité réelle (PR valeur) seule 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. définir la priorité (la fonction qui change la belle valeur) le manuel dit :
L'effet de la modification de la valeur nice peut varier en fonction de l'algorithme de planification de processus en vigueur.
Le manuel de Pthread indique ce qui suit :
La priorité dynamique est basée sur la valeur de nice (définie par nice(2), setpriority(2) ou sched_setattr(2)) et augmentée à chaque fois que le thread est prêt à s'exécuter, mais refusé par le planificateur.
Il semble que PR la valeur correspond à la priorité dynamique.
La gamme des NI la valeur est -20..19 . Ainsi le RP la valeur peut avoir des valeurs à partir de 0 (20 - 20) à 39 (20 + 19). Mais c'est correct uniquement pour les processus avec la politique de planification par défaut (SHED_OTHER ). Il peut également y avoir des processus dits en "temps réel" politiques d'ordonnancement. Ces politiques sont SCHED_RR et SCHED_FIFO . De tels processus ont un PR valeur inférieure à 0. Vous pouvez vérifier cela en exécutant chrt -r 1 top commande (doit être root). Le haut le processus aura PR -2 . Vous pouvez même exécuter chrt -r 90 top auquel cas le haut le processus aura PR -91 .
Il semble que pour SCHED_RR traite le PR la valeur peut être calculée par la formule :
PR =- 1 - sched_rr_priority .
Ainsi un SCHED_RR le processus a au moins PR -1 ce qui signifie que tout SCHED_RR le processus a une priorité plus élevée que n'importe quel SCHED_OTHER . Cela correspond au manuel de 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éemptera 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. Tellement positif PR les valeurs peuvent être traitées comme une priorité dynamique pour les non temps réels (SCHED_OTHER , SCHED_BATCH ) processus et PR négatifs valeur comme priorité statique pour les processus en temps réel (SCHED_RR , SCHED_FIFO ).
J'ai aussi essayé d'exécuter nice -n 10 chrt -r 50 top (et chrt -r 50 nice -n 10 top ). Le NI la valeur était de 10, mais le PR était toujours -51 . Il semble donc que NI la valeur n'affecte pas la priorité de SCHED_RR processus. Cela correspond à setpriority manuel :
Tout processus ou thread utilisant SCHED_FIFO ou SCHED_RR ne sera pas affecté par un appel à setpriority(). Ceci n'est pas considéré comme une erreur. Un processus qui revient ensuite à SCHED_OTHER n'a pas besoin d'avoir sa priorité affectée par un tel appel setpriority().
Une note amusante. Si vous exécutez chrt -r 99 top , vous verrez RT valeur au lieu d'un nombre dans PR colonne.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 28489 root RT 0 2852 1200 896 R 0 0.1 0:00.01 top
Je ne pense pas que cela signifie que le processus est maintenant spécial. Je pense que cela signifie que top n'imprimez pas -100 car il faudrait 4 caractères pour imprimer.
Vous pouvez également utiliser htop au lieu de top dans tous les exemples qui peuvent être plus commodes. 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 va imprimer
F S 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
La valeur nice est un mécanisme "global", alors que la priorité est pertinente pour le sélecteur de tâches actuellement .