Journal sched_deadline est dans les temps

Cher Nal,
Lors de la conférence Embedded Recipes à Paris, SCHED_DEADLINE a fait l'objet d'une présentation claire et accessible à toutes et tous. Un planificateur (ou ordonnanceur) pour CPU est le bout de code qui décide quand une tâche doit être exécuté. Basiquement : l'ordre d'exécution. Cet ordonnanceur pour CPU n'est pas nouveau, mais il va devenir l'ordonnanceur par défaut à partir de Linux 4.14.

SCHED_DEADLINE implémente l'algorithme « le délai au plus tôt possible » (Earliest Deadline First) auquel viennent s'ajouter des priorités dynamiques, et initialement un « mécanisme de bande passante constante » (Constant Bandwidth Server), amélioré par une implémentation du « Greedy Reclamation of Unused Bandwidth (grub)» adaptée au contexte des matériels actuels. En l'état actuel, sched_deadline permet de :

• Ajouter une contrainte de temps sur chaque tâche, de manière déterministe ;
• Permettre la réservation de ressources, et l'isolation comportementale des tâches entre elles (ex : bande passante cpu) ;
• Ne pas imposer pas de style de contraintes (qui peuvent donc être périodiques, a-périodiques ou sporadiques.)

Une tâche trop gourmande ou qui se comporte mal ne pourra pas outrepasser la réservation faite pour elle. Le comportement temporel d'une tâche ne sera donc pas affecté par une autre tâche, offrant ainsi la prédictibilité (qui n'était pas possible avec sched_normal, sched_rr ni sched_fifo) À noter qu'une tâche demandée/marquée/programmée '-deadline' ne peut forker. Les tâches se voient attribuées trois caractères, trois états possibles :

• Inactives: lorsqu'elles sont bloquées et ont dépassé le "temps 0-lag" ;
• Contenu Non Actif (ActiveNonContending) lorsqu'elles sont bloquées mais sans avoir dépassé le "temps 0-lag" ;
• Contenu Actif (ActiveContending) lorsqu'elles sont prêtes à être exécutées (ou sont en cours d'exécution)

Le "contenu non actif" est un état transitoire : lorsqu'une tâche bloque (est bloquée) elle n'entre pas immédiatement en état "inactif", car cela casserait les garanties de temps d'exécution. Elle passe donc par cet état transitoire.

Le calcul de ce "temps 0-lag" pour une tâche passant en état "Contenu Non Actif " (cf : la doc) est ainsi fait :

 (runtime * dl_period)
 deadline - ---------------------
 dl_runtime

Où "runtime" est le temps d'exécution restant, et dl_runtime ainsi que dl_period sont les paramètres de réservation.

Si une tâche qui bloquait redevient active avant que son chrono "timer inactif" soit fini, alors ce dernier est simplement détruit. À noter que si une tâche se réveille / redevient active sur une file d'exécution différente, alors elle sera automatiquement retirée de la file initiale par l'ordonnanceur. Des mécanismes pour éviter des "race conditions" sont implémentés (ex : lorsque le chrono se trouve sur un cpu différent de celui ayant la file d'exécution dans laquelle la tâche se réveille)

L'évolution croissante de la complexité et des possibilités des matériels a rendu la tâche de l'ordonnanceur de plus en plus complexe (parfois hors-sujet ?) SCHED_DEADLINE choisi de ne pas implémenter de configurations accessibles d'affinités : la gestion/configuration des affinités est maintenant déléguée aux CGROUPs (cf : cpuset), qui permettent des ajustements fins tout en offrant une configuration facilitée.

En résumé, SCHED_DEADLINE est un ordonnanceur répondant aux besoins industriels où la prédiction est nécessaire ainsi qu'aux besoins de faibles latences ou/et de temps d'exécution garantis, mais également aux environnements portant des machines virtuelles par une gestion plus équitable des ressources CPU distribuées. Un développement de 10 ans, et demain l'ordonnanceur par défaut dans le noyau Linux.

Deux nouveaux appels systèmes sont implémentés : 'sched_setattr' et 'sched_getattr' , pour aller plus loin lire :
Présentation au Embedded Recipes, par Steven Rostedt
Evidence & Actors-Projets & Retis Lab
Chez vous peut-être ?