5. Priorités et Linux O(1)

5. Priorités et Linux O(1)

5.1 Importance relative et conventions numériques

Une défragmentation peut attendre davantage qu’un jeu en ligne; la vérification périodique du courrier ne demande pas la même réaction qu’un traitement de texte. Une priorité indique un service relatif souhaité. Elle peut jouer sur le moment de sélection, la longueur d’une tranche ou le poids de partage. Donner davantage à une tâche ne crée pas du CPU : les autres participants reçoivent une autre répartition de la même ressource.

Une organisation de base possède une file par niveau. On choisit d’abord le niveau admissible le plus prioritaire, puis une tâche à ce niveau, éventuellement par RR. RR par priorité ne signifie pas faire alterner toutes les tâches indépendamment du niveau. Une file moins prioritaire peut attendre tant que la supérieure contient une tâche prête.

Ne pas transporter la convention d’une colonne à l’autre. Une priorité interne 119 n’est ni nice 119 ni le poids 119.

5.2 Active, expirée et epoch

Le support vise explicitement le noyau Linux 2.6.8.1. C’est un modèle historique : CFS est intégré dans 2.6.23; la documentation actuelle décrit une transition vers EEVDF à partir de 6.6. Ces repères datent le modèle sans ajouter EEVDF à la matière à étudier ici. Documentation du noyau CFS, EEVDF.

O(1) possède par CPU une structure active et une expirée, organisées en 140 niveaux internes 0 à 139. Les tâches ordinaires NORMAL occupent 100 à 139; la bande plus prioritaire 0 à 99 est réservée au temps réel dans le schéma. Une tâche dont la tranche reste à servir est dans l’active. Si elle consomme sa tranche et a encore du travail, elle est préemptée et passe à l’expirée. Lorsque l’active est vide, on échange les pointeurs : l’expirée devient active et un nouvel epoch, ou passage, commence.

Le nombre de niveaux est fixe; la sélection et l’échange ne demandent pas de recalculer individuellement les N tâches à chaque décision. Le nom O(1) concerne ce coût de choix, pas le temps nécessaire pour exécuter tous les travaux. Avec plusieurs CPU, les structures correspondantes permettent du parallélisme; les exercices monoprocesseurs n’exécutent qu’une tâche à la fois.

5.3 FIFO et RR : deux raisons différentes de préempter

SCHED_FIFO n’impose pas de quantum entre tâches de même priorité. La tête garde le CPU jusqu’à sa fin, son blocage ou sa cession, mais une tâche de priorité supérieure devenue prête peut la préempter. « Sans préemption » dans la présentation courte veut donc dire sans rotation forcée par quantum entre pairs, et non immunité à une priorité supérieure.

Le premier schéma place P1 au niveau 0, P2 au 1, P3/P4 au 2, P5 au 3. Sans arrivée supplémentaire : P1→P2→P3→P4→P5. P3 précède P4 par son rang de file. Dans l’animation suivante, P2 n’est pas initialement prêt : P1 finit, P3 commence, puis P2 devient prêt au niveau 1 et interrompt P3 niveau 2. Quand P2 ne monopolise plus le niveau prioritaire, P3 reprend son travail avant son pair P4, puis P5 pourra passer. Aucune durée numérique n’est fournie; ne pas en fabriquer pour le dessin ni recommencer P3 de zéro.

SCHED_RR ajoute un quantum et une rotation à l’intérieur d’un niveau, tout en restant préemptible par un niveau supérieur. Avec P1/P2 au 0, P3/P4 au 2, P5 au 3, la succession illustrée est :

P1 → P2 → P1 → P3 → P4 → P3 → P3 → P3 → P5

On sert le niveau 0 avant 2. P3 et P4 alternent tant qu’ils participent tous deux; P3 seul peut ensuite recevoir des tranches adjacentes. Rien n’oblige à faire passer P5 moins prioritaire pendant ce temps. La barre finale de P5 est schématique et ne définit pas un quantum différent.

Les tâches temps réel prêtes passent avant NORMAL dans le modèle. Une tâche temps réel bloquée ne retient pas le CPU en attendant; l’expression « toutes ont terminé » ne doit pas effacer cette distinction d’état. Une charge prioritaire continuellement prête peut affamer les tâches ordinaires.

Précision technique pour le TP2 : les politiques FIFO et RR peuvent employer les mêmes niveaux de priorité temps réel. Le seul nom FIFO ne classe pas universellement toutes ses tâches au-dessus de toutes les RR. Le niveau sélectionne; la politique règle le comportement entre pairs. Nice à lui seul ne transforme pas une tâche ordinaire en FIFO/RR. Cette qualification vient du manuel Linux sched(7), distinct du schéma pédagogique.

5.4 Nice et correction dynamique de NORMAL

La composante statique assimilée à nice varie de −20 à +19, défaut 0. Positif réduit la priorité, négatif l’augmente; les interfaces citées sont nice et setpriority. Le système ajoute une correction dynamique entre −5 et +5 selon des heuristiques de comportement, notamment le temps bloqué. Le modèle favorise les tâches E/S qui rendent rapidement le CPU afin qu’elles répondent mieux au réveil; une tâche continuellement CPU peut être moins favorisée. Cette adaptation concerne NORMAL, pas les politiques temps réel du modèle.

P_sched = 120 + P_statique + P_dynamique
P_statique ∈ [−20,19]; P_dynamique ∈ [−5,5]
Niveau NORMAL valide : [100,139]

Une somme brute 95 ou 144 ne crée pas un nouveau niveau admissible : les bornes restent 100/139. À nice 0, une correction −5 donne 115, donc davantage de priorité que 120; +5 donne 125, moins prioritaire. Sans comportement E/S ou CPU suffisamment décrit, ne pas inventer une correction dynamique; les valeurs du tableau de tranches utilisent zéro.

Le support dit aussi que la dynamique « augmente » avec le temps bloqué. Lu comme une addition numérique positive, cela contredit la récompense E/Set la convention du petit numéro. Le sens cohérent est l’augmentation du bonus ou de la priorité effective, correspondant à une correction numérique plus négative. Conserver cette discordance de formulation pour éviter d’appliquer deux règles arithmétiques contraires.

5.5 Tranches et passage au prochain epoch

La fonction historique de tranche, en millisecondes, utilise le niveau SP du tableau :

si SP < 120 : T_slice = (140 − SP) × 20 ms
sinon       : T_slice = (140 − SP) ×  5 ms

La fonction est par morceaux; le changement à 120 n’est pas une progression linéaire à coefficient unique. Ces valeurs ne prétendent pas régler tout noyau Linux actuel.

Parcourir l’active à partir de 100. À chaque niveau, servir chaque tâche pour au plus sa tranche; celle qui termine sort, celle qui reste passe à l’expirée. Puis avancer à P+1 lorsque le niveau est vide. Atteindre 140 signifie que les niveaux actifs sont épuisés : échanger les structures et recommencer à 100.

L’exemple associe P3 demandant 140 ms et P4 demandant 43 ms, tous deux au niveau 120, tranche 100 ms. P3 consomme 100 et conserve 40 pour l’expirée. P4 consomme 43 et termine; ne pas réserver 100 à une tâche finie. Le passage de ces deux tâches prend donc 143 ms. Au prochain epoch, P3 finit ses 40 restantes : total 183 ms si elles sont seules. Les ellipses du schéma signalent d’autres tâches actives possibles; leur travail doit passer avant l’échange, donc la reprise de P3 ne suit pas forcément immédiatement P4. Il n’y a pas de données E/S pour modifier leur dynamique dans cet exemple.

5.6 Yield est une cession, pas une synchronisation

sched_yield() exprime une cession volontaire. Le dessin O(1) transfère l’appelant de l’active à l’expirée pour permettre aux autres actives de progresser. Sa phrase sur la réexécution de « tous les autres » décrit ce scénario; l’appel n’est pas une barrière qui prouve que chaque autre thread a exécuté une étape. Un appelant seul au niveau admissible peut continuer, et le comportement ordinaire ne fournit pas un ordre de programme garanti. Pour imposer un ordre logique, utiliser la synchronisation adaptée. Manuel sched_yield.