Journal sched_deadline est dans les temps

Posté par  (Mastodon) . Licence CC By‑SA.
22
15
oct.
2017

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 ?

  • # faille spatiotemporelle ?

    Posté par  . Évalué à 4.

    Cet ordonnanceur pour CPU n'est pas nouveau, mais il va devenir l'ordonnanceur par défaut à partir de Linux 3.14.

    4.14 ?

    • [^] # Re: faille spatiotemporelle ?

      Posté par  (Mastodon) . Évalué à 2.

      En effet ;-)
      Merci

      • [^] # Re: faille spatiotemporelle ?

        Posté par  (site web personnel) . Évalué à 10.

        Bah non justement : SCHED_DEADLINE est dispo depuis Linux 3.14. Et ce n'est pas vraiment un nouveau scheduler, mais une nouvelle classe, qui vient compléter (et non remplacer) SCHED_RR et SCHED_FIFO dans les ordonnancements temps réel, et le SCHED_OTHER pour les processus non temps réel.

        J'ai peut être loupé quelque chose, mais je n'ai rien trouvé qui dise que ça deviendrait la classe par défaut un jour, et en fait je ne vois pas quel sens ça aurait (SCHED_DEADLINE n'est pertinent que dans les contextes où on connaît les deadlines…).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.