Quelle priorité en temps réel est la plus haute priorité sous Linux
Dans la plage de priorité de processus en temps réel Linux 1 à 99, Je ne sais pas quelle est la priorité la plus élevée, 1 ou 99.
La Section 7.2.2 de "comprendre le noyau Linux" (O'Reilly) indique que 1 est la priorité la plus élevée, ce qui est logique étant donné que les processus normaux ont des priorités statiques de 100 à 139, 100 étant la priorité la plus élevée:
" Chaque processus en temps réel est associé à une priorité en temps réel, qui est une valeur allant de 1 (la plus élevée priorité) à 99 (priorité la plus basse). "
D'autre part, la page de manuel sched_setscheduler (RHEL 6.1) prétend que 99 est le plus élevé:
"processus planifiés sous l'une des politiques temps réel (SCHED_FIFO, SCHED_RR) avoir une valeur sched_priority comprise entre 1 (faible) et 99 (élevée)."
Quelle est la priorité en temps réel la plus élevée?
6 réponses
J'ai fait une expérience pour clouer cela, comme suit:
Process1: priorité RT = 40, affinité CPU = CPU 0. Ce processus "tourne" pendant 10 secondes, de sorte qu'il ne laissera aucun processus de priorité inférieure s'exécuter sur CPU 0.
Process2: priorité RT = 39, affinité CPU = CPU 0. Ce processus imprime un message sur stdout toutes les 0,5 secondes, en dormant entre les deux. Il imprime le temps écoulé avec chaque message.
J'exécute un noyau 2.6.33 avec le PREEMPT_RT patch.
Pour exécuter l'expérience, j'exécute process2 dans une fenêtre (en tant que root), puis je lance process1 (en tant que root) dans une autre fenêtre. Le résultat est process1 semble préempter process2, ne lui permettant pas de s'exécuter pendant 10 Secondes complètes.
Dans une seconde expérience, je change la priorité RT de process2 à 41. Dans ce cas, process2 est pas préempté par process1.
Cette expérience montre qu'une valeur de prioritéplus grande RT dans sched_setscheduler() a une priorité plus élevée. Cela semble contredire ce que Michael Foukarakis a souligné de sched.h, mais en fait, il ne le fait pas. Dans sched.c dans la source du noyau, nous avons:
static void
__setscheduler(struct rq *rq, struct task_struct *p, int policy, int prio)
{
BUG_ON(p->se.on_rq);
p->policy = policy;
p->rt_priority = prio;
p->normal_prio = normal_prio(p);
/* we are holding p->pi_lock already */
p->prio = rt_mutex_getprio(p);
if (rt_prio(p->prio))
p->sched_class = &rt_sched_class;
else
p->sched_class = &fair_sched_class;
set_load_weight(p);
}
Rt_mutex_getprio (p) fait ce qui suit:
return task->normal_prio;
Alors que normal_prio () arrive à faire ce qui suit:
prio = MAX_RT_PRIO-1 - p->rt_priority; /* <===== notice! */
...
return prio;
En d'autres termes, nous avons (ma propre interprétation):
p->prio = p->normal_prio = MAX_RT_PRIO - 1 - p->rt_priority
Wow! C'est déroutant! Pour résumer:
Avec P - > prio, une valeur plus petite préempte une valeur plus grande valeur.
Avec P - > rt_priority, une valeur plus grande préempte une valeur plus petite. C'est la priorité en temps réel définie à l'aide de sched_setscheduler().
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 .
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.
Votre hypothèse selon laquelle les processus normaux ont des priorités statiques de 100 à 139 est volatile au mieux et invalide au pire. Ce que je veux dire, c'est que: set_scheduler permet seulement à sched_priority d'être 0 (ce qui indique un planificateur de priorité dynamique) avec SCHED_OTHER / SCHED_BATCH et SCHED_IDLE (true à partir de 2.6.16).
Les priorités statiques par programmation sont 1-99 uniquement pour SCHED_RR et SCHED_FIFO
Maintenant, vous pouvez voir les priorités de 100-139 utilisées en interne par un planificateur dynamique howeve, r ce que le noyau fait en interne pour gérer les priorités dynamiques (y compris en retournant la signification de priorité élevée ou faible pour faciliter la comparaison ou le tri) devrait être opaque pour l'espace utilisateur.
Rappelez - vous dans SCHED_OTHER que vous bourrez principalement les processus dans la même file d'attente prioritaire.
L'idée est de rendre le noyau plus facile à déboguer et d'éviter les erreurs maladroites.
Donc, la raison de changer la signification pourrait être qu'en tant que développeur de noyau ne le fait pas souhaitez utiliser les mathématiques comme 139-idx (juste au cas où idx > 139) ... il est préférable de faire des calculs avec idx-100 et d'inverser le concept de faible vs élevé car idx
Aussi un effet secondaire est que la gentillesse devient plus facile à traiter. 100-100 nice = = 0; 101-100 nice = = 1; etc. est plus facile. Il s'effondre aussi bien en nombres négatifs (rien à voir avec les priorités statiques) 99 - 100 nice == -1 ...
- absolument, la priorité en temps réel est applicable aux politiques RT FIFO et RR qui varie de 0 à 99.
-
Nous avons le 40 comme compte de la priorité de processus non en temps réel pour BATCH, D'autres politiques qui varient 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 processus en temps réel. Il portera un PR de 20 et une gentillesse de 0 par défaut. Si vous diminuez la gentillesse d'un processus (généralement, inférieur ou négatif le nombre moindre la gentillesse, plus faim le processus), dire de 0 à -1, Vous ' ll observer que la priorité va tomber à 19 de 20. Cela dit simplement que, si vous faites un processus plus faim ou souhaitez obtenir un peu plus d'attention en diminuant la valeur de gentillesse du PID, vous obtiendrez une diminution de la priorité aussi, abaissez ainsi le numéro de priorité plus élevé la priorité.
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 [admin@abc.com ~]# renice -n -11 2079 2079: old priority -10, new priority -11 [admin@abc.com ~]# 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, si tout.
Réponse Courte
99 sera le gagnant pour la priorité en temps réel.
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)
Réponse Longue
Il y en a 2 types de processus, les normaux et les temps réel Pour les normales (et seulement pour celles-ci), nice est appliqué comme suit:
Nice
L'échelle de "gentillesse" va de -20 à 19, alors que -20 c'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 de nice et PR est le niveau de priorité. Donc, comme nous pouvons le voir, le -20 correspond réellement à 0, tandis que le 19 cartes à 39.
Par défaut, une valeur de Nice de programme est 0 bit il est possible pour un utilisateur root de déjeuner des programmes avec une valeur de nice spécifiée en utilisant la commande suivante:
nice -n <nice_value> ./myProgram
Temps Réel
Nous pourrions aller encore plus loin. La priorité nice est en fait utilisée pour les programmes utilisateur. Alors que la priorité globale UNIX/LINUX a une plage de 140 valeurs, nice value permet au processus de mapper la dernière partie de la plage (de 100 à 139). Cette équation laisse les valeurs de 0 à 99 inaccessible qui correspondra à un niveau PR négatif (de -100 à -1). Pour pouvoir accéder à ces valeurs, le processus doit être déclaré en "temps réel".
Il existe 5 stratégies 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 stratégies d'ordonnancement normales (1 à 3) et les stratégies 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é en utilisant la commande suivante (L'exemple est comment déclarer une politique SCHED_RR):
chrt --rr <priority between 1-99> ./myProgram
Pour obtenir la valeur de PR pour un processus en temps réel, l'équation suivante est appliquée:
PR = -1-rt_prior
Où rt_prior correspond à la priorité comprise entre 1 et 99. Pour cette raison le processus qui aura la plus haute priorité sur les autres processus sera celui qui a 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
Qui affiche la sortie suivante:
Dans la figure, les valeurs PR et NI sont affichées. Il est bon de noter le processus avec la valeur PR -51 qui correspond à une valeur en temps réel. Il y a aussi quelques processus dont la valeur PR est indiquée comme "rt". Cette valeur correspond en fait à une valeur PR de -100.