Différence entre la valeur agréable et la priorité dans la sortie supérieure


11

en haut , par défaut, répertorie les deux colonnes. Je suis curieux de savoir quelle est la différence. J'ai vérifié les pages de manuel et je ne peux pas le comprendre:

Priorité:

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

Belle valeur:

   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.

Je comprends que la valeur Nice est liée à la file d'attente du planificateur CPU du noyau; alors qu'est-ce que la priorité indique? Quelque chose concernant les E / S peut-être?

Réponses:


8

La bonne valeur est un mécanisme "global", alors que la priorité est pertinente pour le sélecteur de tâches en ce moment .


Qu'entendez-vous par sélecteur de tâches?
Belmin Fernandez

1
Le sélecteur de tâches (correctement appelé "planificateur") est un peu de code au sein du noyau qui décide de la tâche à exécuter ensuite.
Ignacio Vazquez-Abrams

25

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 topdans 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 topcommande (vous devez être root). Le processus supérieur aura PR -2 . Vous pouvez même exécuter chrt -r 90 topdans 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 -lpeut é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 -limprimera

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

Curieusement, si je lance 5 boucles infinies (int main {while (1);}) sur un i3 hyperthreadé à 2 cœurs, leurs priorités restent constantes. Ceci dans les tests Debian Sid.
Vorac

1
@BelminFernandez Je pense qu'il sera juste de rendre cette réponse "acceptée".
z0lupka

1

Réponse courte

PR est le niveau de priorité. Plus le PR est bas, plus la priorité du processus sera élevée.

PR est calculé comme suit:

  • pour les processus normaux: PR = 20 - NI (NI est agréable et varie de -20 à 19)
  • pour les processus en temps réel: PR = - 1 - real_time_priority (real_time_priority varie de 1 à 99)

Longue réponse

Il existe 2 types de processus, les normaux et le temps réel Pour les normaux (et uniquement pour ceux-ci), nice est appliqué comme suit:

Agréable

L'échelle de "gentillesse" va de -20 à 19, alors que -20 est la priorité la plus élevée et 19 la priorité la plus basse. Le niveau de priorité est calculé comme suit:

PR = 20 + NI

Où NI est le niveau agréable et PR est le niveau prioritaire. Donc, comme nous pouvons le voir, le -20 correspond à 0, tandis que le 19 correspond à 39.

Par défaut, une valeur agréable de programme est 0 bit, il est possible pour un utilisateur root de déjeuner des programmes avec une valeur agréable spécifiée en utilisant la commande suivante:

nice -n <nice_value> ./myProgram 

Temps réel

On pourrait aller encore plus loin. La belle priorité est en fait utilisée pour les programmes utilisateur. Alors que la priorité globale UNIX / LINUX a une plage de 140 valeurs, une valeur sympa permet au processus de correspondre à la dernière partie de la plage (de 100 à 139). Cette équation laisse les valeurs de 0 à 99 inaccessibles ce qui correspondra à un niveau PR négatif (de -100 à -1). Pour pouvoir accéder à ces valeurs, le processus doit être indiqué en "temps réel".

Il existe 5 politiques de planification dans un environnement LINUX qui peuvent être affichées avec la commande suivante:

chrt -m 

Qui affichera la liste suivante:

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

Les processus d'ordonnancement peuvent être divisés en 2 groupes, les politiques d'ordonnancement normales (1 à 3) et les politiques d'ordonnancement en temps réel (4 et 5). Les processus en temps réel auront toujours la priorité sur les processus normaux. Un processus en temps réel peut être appelé à l'aide de la commande suivante (l'exemple est de savoir comment déclarer une stratégie SCHED_RR):

chrt --rr <priority between 1-99> ./myProgram

Pour obtenir la valeur PR pour un processus en temps réel, l'équation suivante est appliquée:

PR = -1 - rt_prior

Où rt_prior correspond à la priorité entre 1 et 99. Pour cette raison, le processus qui aura la priorité la plus élevée sur les autres processus sera celui appelé avec le numéro 99.

Il est important de noter que pour les processus en temps réel, la valeur nice n'est pas utilisée.

Pour voir la "gentillesse" actuelle et la valeur PR d'un processus, la commande suivante peut être exécutée:

top

Il est bon de noter que les processus avec une valeur PR -51 par exemple correspondent à une valeur en temps réel. Il existe également certains processus dont la valeur PR est indiquée comme "rt". Cette valeur correspond en fait à une valeur PR de -100.

(PS: j'aurais posté une photo montrant le meilleur résultat mais je n'ai pas la réputation de le faire)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.