linux-kernel d'un - Quelle priorité en temps réel est la plus haute priorité sous Linux




afficher processus (5)

Pour déterminer la priorité en temps réel la plus élevée que vous pouvez définir par programme, utilisez la fonction sched_get_priority_max.

Sous Linux 2.6.32, un appel à sched_get_priority_max (SCHED_FIFO) renvoie 99.

Voir http://linux.die.net/man/2/sched_get_priority_max

Dans la plage de priorités de processus en temps réel Linux 1 à 99, il n'est pas clair pour moi quelle est la plus haute priorité, 1 ou 99.

La section 7.2.2 de «Comprendre le noyau Linux» (O'Reilly) dit que 1 est la plus haute priorité, ce qui est logique étant donné que les processus normaux ont des priorités statiques de 100 à 139, 100 étant la plus haute priorité:

"Chaque processus en temps réel est associé à une priorité en temps réel, qui va de 1 (priorité la plus élevée) à 99 (priorité la plus basse)."

D'un autre côté, la page de manuel sched_setscheduler (RHEL 6.1) affirme que 99 est le plus élevé:

"Les processus planifiés sous l'une des politiques en temps réel (SCHED_FIFO, SCHED_RR) ont une valeur sched_priority comprise entre 1 (faible) et 99 (élevé)."

Quelle est la plus haute priorité en temps réel?


  1. Absolument, la priorité en temps réel est applicable aux politiques RT FIFO et RR qui varie de 0 à 99.
  2. Nous avons les 40 comme un compte de la priorité de processus non temps réel pour BATCH, AUTRES politiques qui varie de 0 à 39 pas de 100 à 139. Ceci, vous pouvez observer en regardant n'importe quel processus dans le système qui n'est pas un temps réel processus. Il portera un PR de 20 et NIceness de 0 par défaut. Si vous diminuez la gentillesse d'un processus (habituellement, plus le nombre est petit ou négatif, plus le processus est affamé), disons de 0 à -1, vous remarquerez que la priorité passera de 19 à 20. Cela dit simplement Si, par exemple, vous faites un processus plus affamé ou que vous souhaitez obtenir un peu plus d'attention en diminuant la valeur de gentillesse du PID, vous perdez également en priorité, abaissant ainsi le PRIORITY number de la PRIORITY.

    Example:
    
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    2079 admin     10 -10  280m  31m 4032 S  9.6  0.0  21183:05 mgmtd
    [[email protected] ~]# renice -n -11 2079
    2079: old priority -10, new priority -11
    [[email protected] ~]# top -b | grep mgmtd
    2079 admin      9 -11  280m  31m 4032 S  0.0  0.0  21183:05 mgmtd
    ^C
    

Espérons que cet exemple pratique clarifie les doutes et peut aider à corriger les mots à la source incorrecte, le cas échéant.


Votre hypothèse selon laquelle les processus normaux ont des priorités statiques de 100 à 139 est au mieux volatile et invalide au pire. Ce que je veux dire, c'est que: set_scheduler n'autorise que sched_priority à 0 (ce qui indique le planificateur de priorité dynamique) avec SCHED_OTHER / SCHED_BATCH et SCHED_IDLE (vrai à partir de 2.6.16).

Les priorités statiques programmatiques sont 1-99 seulement pour SCHED_RR et SCHED_FIFO

Maintenant, vous pouvez voir les priorités de 100-139 utilisées en interne par un planificateur dynamique, mais ce que le noyau fait en interne pour gérer les priorités dynamiques (y compris inverser la signification de haute ou basse priorité pour faciliter la comparaison ou le tri) devrait être opaque à l'espace utilisateur.

Rappelez-vous que dans SCHED_OTHER, vous bourrez principalement les processus dans la même file d'attente de priorité.

L'idée est de rendre le noyau plus facile à déboguer et d'éviter les erreurs loufoques hors-limite.

Donc le raisonnement dans le changement de sens pourrait être que comme un développeur de noyau ne veut pas utiliser des maths comme 139-idx (juste dans le cas idx> 139) ... il est préférable de faire des maths avec idx-100 et inverser le concept de bas vs haut parce que idx <100 est bien compris.

Un effet secondaire est également que la gentillesse devient plus facile à traiter. 100 - 100 <=> gentil == 0; 101-100 <=> gentil == 1; etc. est plus facile. Il se réduit bien aux nombres négatifs (RIEN à faire avec les priorités statiques) 99 - 100 <=> nice == -1 ...


Ce commentaire dans sched.h est assez définitif:

/*
 * 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.
 */

Notez cette partie:

Les valeurs de priorité sont inversées: une valeur inférieure p->prio signifie une priorité plus élevée .


Cela dépend si ce noyau est compilé avec les fonctionnalités requises pour exécuter les conteneurs. Si c'est le cas, alors Docker pourrait être utilisé sur Android (en particulier Docker 0.7, qui est actuellement en état de candidat à la publication, et ne nécessite plus de AUFS).





linux linux-kernel real-time