Quelle priorité en temps réel est la plus haute priorité sous Linux


Answers

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 .

Question

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?




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