Provided by: manpages-fr_4.13-4_all bug

NOM

       sched – Aperçu de l’ordonnancement de CPU

DESCRIPTION

       Depuis  Linux 2.6.23,  l’ordonnanceur  par  défaut  est  CFS  (Completely  Fair  Scheduler
       – ordonnanceur complètement équitable). Il remplace l’ordonnanceur précédent, « O(1) ».

   Résumé des API
       Linux  fournit  les  appels  système  suivants   pour   contrôler   le   comportement   de
       l’ordonnancement  du CPU, la politique et la priorité des processus (ou, plus précisément,
       des threads).

       nice(2)
              Définir une nouvelle valeur de politesse pour le thread appelant et renvoyer  cette
              nouvelle valeur.

       getpriority(2)
              Renvoyer  la  valeur  de  politesse  d’un  thread,  d’un  groupe de processus ou de
              l’ensemble des threads possédés par un utilisateur particulier.

       setpriority(2)
              Définir la valeur de  politesse  d’un  thread,  d’un  groupe  de  processus  ou  de
              l’ensemble des threads possédés par un utilisateur particulier.

       sched_setscheduler(2)
              Définir la politique d'ordonnancement et les paramètres du thread indiqué.

       sched_getscheduler(2)
              Renvoyer la politique d'ordonnancement du thread indiqué.

       sched_setparam(2)
              Définir les paramètres d'ordonnancement du thread indiqué.

       sched_getparam(2)
              Récupérer les paramètres d'ordonnancement du thread indiqué.

       sched_get_priority_max(2)
              Renvoyer  la  priorité  la plus haute disponible pour la politique d'ordonnancement
              indiquée.

       sched_get_priority_min(2)
              Renvoyer la priorité la plus basse disponible pour  la  politique  d'ordonnancement
              indiquée.

       sched_rr_get_interval(2)
              Récupérer  le  quantum de temps alloué utilisé pour les threads ordonnancés par une
              politique de type répartition par tourniquet (round robin).

       sched_yield(2)
              Provoquer la libération  du  CPU  par  l'appelant  afin  de  permettre  l’exécution
              d'autres threads.

       sched_setaffinity(2)
              Définir le masque d'affinité CPU du thread indiqué (propre à Linux).

       sched_getaffinity(2)
              Récupérer le masque d'affinité CPU du thread indiqué (propre à Linux).

       sched_setattr(2)
              Définir  la  politique  d'ordonnancement  et  les paramètres du thread indiqué. Cet
              appel système (propre à Linux) fournit un  sur-ensemble  de  la  fonctionnalité  de
              sched_setscheduler(2) et de sched_setparam(2).

       sched_getattr(2)
              Récupérer  la  politique  d'ordonnancement et les paramètres du thread indiqué. Cet
              appel système (propre à Linux) fournit un  sur-ensemble  de  la  fonctionnalité  de
              sched_getscheduler(2) et de sched_getparam(2).

   Politiques d'ordonnancement
       L'ordonnanceur est la partie du noyau qui décide quel thread prêt va être exécuté ensuite.
       Chaque  processus  a   une   politique   d'ordonnancement   associée   et   une   priorité
       d'ordonnancement  statique, sched_priority. L'ordonnanceur prend ses décisions en fonction
       de la politique d'ordonnancement et de  la  priorité  statique  de  tous  les  threads  du
       système.

       Pour   les  threads  ordonnancés  sous  l'une  des  politiques  d'ordonnancement  normales
       (SCHED_OTHER,  SCHED_IDLE,  SCHED_BATCH),  sched_priority  n'est  pas  utilisée  dans  les
       décisions d'ordonnancement (et doit valoir 0).

       Les   processus   ordonnancés  sous  l'une  des  politiques  d'ordonnancement  temps  réel
       (SCHED_FIFO, SCHED_RR) ont une valeur sched_priority  dans  l'intervalle 1  (faible)  à 99
       (haute). (Comme les nombres l'impliquent, les threads temps réel ont toujours une priorité
       plus haute que les threads normaux.)  Notez  bien :  POSIX.1  exige  d'une  implémentation
       qu'elle  gère seulement un minimum de 32 niveaux de priorité distincts pour les politiques
       temps réel et certains systèmes n'offrent que ce minimum. Les programmes portables doivent
       utiliser    sched_get_priority_min(2)    et   sched_get_priority_max(2)   pour   connaître
       l'intervalle des priorités gérées pour une politique particulière.

       Théoriquement, l'ordonnanceur  entretient  une  liste  de  tous  les  threads  prêts  pour
       l’exécution  pour  chaque  valeur  possible  de  sched_priority.  Afin  de déterminer quel
       processus doit s'exécuter ensuite, l'ordonnanceur recherche la  liste  non  vide  de  plus
       haute priorité statique et choisit le thread en tête de cette liste.

       La  politique  d'ordonnancement d'un thread détermine l'emplacement où il sera inséré dans
       la liste contenant les threads de même priorité statique et comment il se  déplacera  dans
       cette liste.

       Tout  ordonnancement  est  préemptif : si un thread avec une priorité statique plus élevée
       devient prêt, le thread actuellement en cours d'exécution est interrompu et retourne  dans
       la  liste  d'attente  avec  son niveau de priorité statique. La politique d'ordonnancement
       détermine l'ordre utilisé seulement dans la liste de  threads  prêts  avec  des  priorités
       statiques égales.

   SCHED_FIFO : Ordonnancement premier entré, premier sorti
       SCHED_FIFO  ne  peut être utilisée qu'avec des priorités statiques supérieures à 0, ce qui
       signifie que dès qu'un thread SCHED_FIFO devient prêt, il préempte n’importe  quel  thread
       SCHED_OTHER,   SCHED_BATCH   ou   SCHED_IDLE  en  cours  d'exécution.  SCHED_FIFO  est  un
       ordonnancement simple sans découpage temporel.  Pour  les  threads  ordonnancés  selon  la
       politique SCHED_FIFO, les règles suivantes sont appliquées :

       1) Un  thread  SCHED_FIFO  qui  a  été préempté par un autre thread de priorité supérieure
          restera en tête de liste pour sa priorité et reprendra son exécution dès que  tous  les
          threads de priorité supérieure seront à nouveau bloqués.

       2) Quand  un  thread SCHED_FIFO bloqué devient prêt, il est inséré en fin de liste pour sa
          priorité.

       3) Si   un   appel   à   sched_setscheduler(2),    sched_setparam(2),    sched_setattr(2),
          pthread_setschedparam(3)  ou  pthread_setschedprio(3)  modifie  la  priorité  du thread
          SCHED_FIFO prêt ou en cours d’exécution, identifié par pid, l’effet sur la position  du
          thread  dans  la  liste  dépend  de  la direction de la modification de la priorité des
          threads :

            •
             Si la priorité du thread est relevée, il est placé en fin de liste pour sa  nouvelle
             priorité.  Par conséquent, il peut préempter un thread en cours d’exécution ayant la
             même priorité.

            •
             Si la priorité du thread est inchangée, sa position dans la liste des exécutions est
             inchangée.

            •
             Si  la  priorité  du  thread  est  abaissée,  il  est placé en tête de liste pour sa
             nouvelle priorité.

          Selon POSIX.1-2008, les modifications de priorité (ou politique) de thread en utilisant
          tout  autre  mécanisme que pthread_setschedprio(3) devraient aboutir à ce que le thread
          soit placé en fin de liste pour sa priorité.

       4) Un thread appelant sched_yield(2) sera placé en fin liste.

       Aucun autre événement ne déplacera un thread ordonnancé selon la politique SCHED_FIFO dans
       la liste d’attente des threads prêts de priorité statique équivalente.

       Un   thread   SCHED_FIFO   s'exécute   jusqu'à  ce  qu'il  soit  bloqué  par  une  requête
       d'entrée-sortie, qu'il soit préempté par un thread de priorité supérieure ou qu'il appelle
       sched_yield(2).

   SCHED_RR : ordonnancement tourniquet
       SCHED_RR est une amélioration simple de SCHED_FIFO. Tout ce qui est décrit pour SCHED_FIFO
       s'applique aussi à SCHED_RR, sauf que chaque thread ne dispose que d'un quantum  de  temps
       maximal pour son exécution. Si l’exécution d’un thread SCHED_RR est d’une durée supérieure
       ou égale au quantum de temps, il sera placé en fin de liste pour sa  priorité.  Un  thread
       SCHED_RR  qui  a  été  préempté par un thread de priorité supérieure et par conséquent qui
       reprend l’exécution en tant que thread en cours, terminera la part  non  utilisée  de  son
       quantum  de  temps  dans  le  tourniquet. La valeur du quantum de temps peut être lue avec
       sched_rr_get_interval(2).

   SCHED_DEADLINE: ordonnancement sur échéances selon le modèle des tâches sporadiques.
       Depuis  la  version  3.14,  Linux  offre  une  politique  d'ordonnancement  sur  échéances
       (SCHED_DEADLINE).  L'implémentation actuelle de cette politique repose sur les algorithmes
       GEDF (Global Earliest Deadline First, ou « priorité globale à l'échéance proche ») et  CBS
       (Constant   Bandwidth   Server,  ou  « serveur  à  bande  passante  constante »)  utilisés
       conjointement. Pour définir ou récupérer cette politique et ses  attributs  associés,  les
       appels système sched_setattr(2) et sched_getattr(2) doivent être utilisés.

       Une  tâche  sporadique  présente  une séquence de sous-tâches qui sont chacune activées au
       moins une fois par période. Chaque sous-tâche a également  une  échéance  relative,  avant
       laquelle  elle  doit  achever  son exécution, et un temps d'exécution qui est le temps CPU
       nécessaire pour qu'elle s'exécute. Le moment auquel une tâche  est  activée  parce  qu'une
       sous-tâche  doit  être  exécutée  est  appelé  temps d'activation (également désigné temps
       d'appel (« request time ») ou  temps  de  libération  (« release  time »)).  Le  temps  de
       lancement  est le moment auquel la tâche commence son exécution. L'échéance impérative est
       obtenue en additionnant l'échéance relative et le temps d'activation.

       Le schéma suivant illustre ces termes :

           activation/réveil                    échéance impérative
                |    temps du lancement                   |
                |        |                                |
                v        v                                v
           -----x--------xoooooooooooooooooooooooo--------x--------x---
                         |<- temps d'exécution ->|
                |<---------- échéance relative ---------->|
                |<----------------- période ---------------------->|

       Lorsqu'une politique SCHED_DEADLINE est activée  au  moyen  de  sched_setattr(2),  il  est
       possible  de  préciser  trois  paramètres : Runtime, Deadline et Period. Ces paramètres ne
       correspondent pas forcément aux termes décrits précédemment : il est d'usage d'affecter  à
       Runtime  une  valeur  supérieure  au temps d'exécution moyen (ou le pire temps d'exécution
       possible, pour les cas de temps réel extrêmes) ; Deadline prend la  valeur  de  l'échéance
       relative ;  enfin,  Period  reçoit  la  valeur  de  la période de la tâche. Ainsi, pour un
       ordonnancement SCHED_DEADLINE, on obtient.

           activation/réveil                    échéance impérative
                |    temps du lancement                   |
                |        |                                |
                v        v                                v
           -----x--------xoooooooooooooooooooooooo--------x--------x---
                         |<------- Exécution ------->|
                |<----------------- Échéance ------------>|
                |<----------------- Période ---------------------->|

       Les trois paramètres de configuration de l'ordonnancement sur échéances correspondent  aux
       champs sched_runtime, sched_deadline et sched_period de la structure sched_attr (consultez
       sched_setattr(2)). Ces champs sont exprimés en nanosecondes. Si la valeur 0 est affectée à
       sched_period, ce paramètre prend la valeur de sched_deadline.

       Le noyau exige que :

           sched_runtime <= sched_deadline <= sched_period

       De  plus, dans l'implémentation actuelle, tous les paramètres doivent valoir au moins 1024
       (c'est à  dire  à  peine  plus  qu'une  microseconde,  qui  est  la  résolution  de  cette
       implémentation)  et  moins  de 2^63.  Si  la  valeur de l'un de ces paramètres sort de cet
       intervalle, sched_setattr(2) échoue en renvoyant l'erreur EINVAL.

       Le CBS assure que les différentes tâches n'interfèrent pas en  bloquant  les  threads  qui
       tentent de dépasser leur temps d'exécution (Runtime).

       Pour  que  les  conditions requises par l'ordonnancement sur échéances soient remplies, le
       noyau doit empêcher des situations dans lesquelles l’ensemble des  threads  SCHED_DEADLINE
       n’est  pas  réalisable  (ordonnancement  non  possible)  en  tenant compte des contraintes
       données.  Le  noyau  doit  donc  exécuter  un  test  d'approbation  lorsque  la  politique
       SCHED_DEADLINE et ses attributs sont définis ou modifiés. Ce test d'approbation valide que
       le changement demandé est réalisable ; si ce n'est pas le cas, sched_setattr(2) échoue  et
       renvoie l'erreur EBUSY.

       Par  exemple,  il  est  nécessaire  (et par forcément suffisant) pour l'utilisation totale
       d'être inférieure ou égale au nombre total de CPU disponibles, où, puisque  chaque  thread
       peut  s'exécuter  au  plus  pour Runtime par Period, l'utilisation pour ce thread vaut son
       Runtime divisé par sa Period.

       Pour assurer les conditions qui sont requises lorsqu'un thread est autorisé à utiliser  la
       politique  SCHED_DEADLINE, les threads SCHED_DEADLINE ont la priorité la plus élevée parmi
       tous les threads (contrôlable par l'utilisateur) du système. Si un thread ordonnancé selon
       SCHED_DEADLINE  est  prêt,  il  aura  la priorité sur tout autre thread ordonnancé par une
       autre politique.

       Un appel à fork(2) effectué par un thread ordonnancé  selon  la  politique  SCHED_DEADLINE
       échouera en renvoyant l'erreur EAGAIN, sauf dans le cas ou l'attribut « reset-on-fork » du
       thread est activé (voir plus bas).

       Un thread ordonnancé selon SCHED_DEADLINE qui appelle sched_yield(2) cédera la priorité  à
       la sous-tâche en cours et attendra une nouvelle période pour débuter.

   SCHED_OTHER : ordonnancement temps partagé par défaut
       SCHED_OTHER  peut être utilisé seulement pour la priorité statique 0 (c’est-à-dire que les
       threads sous politique  temps  réel  ont  la  priorité  sur  les  processus  SCHED_OTHER).
       SCHED_OTHER  est l’ordonnanceur temps partagé de Linux prévu pour tous les threads n’ayant
       pas besoin des mécanismes temps réel spéciaux.

       Le thread à exécuter est choisi dans la liste  des  threads  de  priorité  statique 0,  en
       utilisant  une  priorité  dynamique  qui  ne  s'applique que dans cette liste. La priorité
       dynamique est basée sur la valeur de politesse (« nice ») du thread (voir  ci-dessous)  et
       est  incrémentée à chaque quantum de temps où le thread est prêt, mais non sélectionné par
       l'ordonnanceur. Cela garantit une progression équitable de tous les threads SCHED_OTHER.

       Dans le code source  du  noyau  Linux,  la  politique  SCHED_OTHER  est  en  fait  appelée
       SCHED_NORMAL.

   La valeur de politesse
       La valeur de politesse est un attribut pouvant être utilisé pour influencer l’ordonnanceur
       en faveur ou défaveur  d’un  processus  dans  les  choix  d’ordonnancement.  Elle  affecte
       l’ordonnancement  des processus SCHED_OTHER et SCHED_BATCH (voir ci-dessous). La valeur de
       politesse peut être modifiée avec nice(2), setpriority(2) ou sched_setattr(2).

       Selon POSIX.1, la valeur de politesse est un attribut par processus, c’est-à-dire que  les
       threads  dans  un  processus  devraient  partager  la valeur de politesse. Cependant, dans
       Linux, cette valeur est un attribut par  thread :  des  threads  distincts  dans  le  même
       processus peuvent avoir des valeurs de politesse différentes.

       L’éventail  des  valeurs  de  politesse  diffère  selon  les  systèmes UNIX. Dans un Linux
       moderne, il varie de −20 (priorité élevée) à +19 (priorité basse).  Dans  quelques  autres
       systèmes,  la  plage  est  de  −20 à 20.  Les tout premiers noyaux Linux (avant Linux 2.0)
       avaient une plage de −infini à 15 .

       De même, le degré auquel la valeur de politesse  affecte  l’ordonnancement  respectif  des
       processus SCHED_OTHER varie selon les systèmes UNIX et selon les versions du noyau Linux.

       Avec  l’arrivée  de  l’ordonnanceur CFS dans le noyau 2.6.23, Linux a adopté un algorithme
       qui provoque des différences relatives aux valeurs  de  politesse  ayant  un  impact  plus
       important.  Dans l’implémentation actuelle, chaque unité de différence dans les valeurs de
       politesse  dans  deux  processus  aboutit  à  un  facteur  de 1,25  dans  le  degré   dont
       l’ordonnancement  favorise  le  processus  de  plus haute priorité. Cela fait que les très
       petites valeurs de priorité (+19) fournissent vraiment peu de  CPU  pour  un  processus  à
       chaque  fois  qu’il  existe une charge de plus haute priorité sur le système, et cela fait
       que les hautes valeurs (−20) fournissent la plus grande partie du CPU aux applications  en
       ayant besoin (par exemple, certaines applications audio).

       Dans Linux, la limite de ressources RLIMIT_NICE peut être utilisée pour définir une limite
       jusqu'à laquelle une valeur de politesse de processus non  privilégié  peut  être  élevée.
       Consultez setrlimit(2) pour les détails.

       Pour davantage d’explications à propos de la valeur de politesse, consultez ci-dessous les
       sous-sections sur la fonctionnalité d’autogroupe et sur l’ordonnancement de groupe.

   SCHED_BATCH : ordonnancement de processus par lots
       (Depuis Linux 2.6.16) SCHED_BATCH ne peut être  utilisée  qu'avec  une  priorité  statique
       de 0.  Cette  politique  est  similaire à SCHED_OTHER en ce qu'elle ordonnance les threads
       conformément à leur priorité dynamique (basée sur la valeur de politesse).  La  différence
       est que cette politique fera que l'ordonnanceur considérera toujours que ce thread demande
       beaucoup de ressources processeur. Par conséquent, il lui appliquera une  petite  pénalité
       d'ordonnancement  vis-à-vis  du  comportement  au  réveil, ainsi le thread sera légèrement
       désavantagé dans les décisions d'ordonnancement.

       Cette politique est utile pour les charges  de  travail  non  interactives,  mais  qui  ne
       souhaitent pas diminuer leur valeur de politesse, ou pour celles qui veulent une politique
       d'ordonnancement  déterministe  sans  que  l'interactivité   ne   cause   de   préemptions
       supplémentaires (entre les tâches des charges).

   SCHED_IDLE : ordonnancement de tâches de très faible priorité
       (Depuis  Linux  2.6.23.)  SCHED_IDLE  ne  peut être utilisée qu'avec une priorité statique
       de 0 ; la valeur de politesse n'a pas d'influence pour cette politique.

       Cette politique est conçue pour l'exécution de tâches de très faible priorité  (inférieure
       même à une valeur de politesse +19 avec les politiques SCHED_OTHER ou SCHED_BATCH).

   Réinitialiser la politique d'ordonnancement pour les processus enfant
       Chaque thread possède un attribut d'ordonnancement reset-on-fork. Lorsque cet attribut est
       défini,  les  enfants  créés  au  moyen  de  fork(2)   n'héritent   pas   des   politiques
       d'ordonnancement nécessitant des droits. L'attribut reset-on-fork peut être défini soit :

       –  en  appliquant un OU logique à l'attribut SCHED_RESET_ON_FORK dans l'argument policy au
          moment de l'appel à sched_setscheduler(2) (à partir de Linux 2.6.32) ;

       –  ou en ajoutant l'argument SCHED_FLAG_RESET_ON_FORK dans attr.sched_flags au  moment  de
          l'appel à sched_setattr(2).

       Notez  que  les  constantes  utilisées  dans  ces  deux  API  ont  des noms différents. La
       disposition de l'attribut reset-on-fork peut, de façon analogue, être obtenue au moyen  de
       sched_getscheduler(2) et de sched_getattr(2).

       La  fonctionnalité reset-on-fork est prévue pour des applications de lecture audiovisuelle
       et peut être utilisée pour  empêcher  les  applications  de  passer  outre  la  limite  de
       ressource RLIMIT_RTTIME (consultez getrlimit(2)) en créant de nombreux processus enfant.

       Plus  précisément,  si  l'attribut  reset-on-fork est utilisé, les règles suivantes seront
       appliquées lors de la création ultérieure des enfants :

       –  Si le thread appelant a une  politique  d'ordonnancement  SCHED_FIFO  ou  SCHED_RR,  la
          politique pour les processus enfant est réinitialisée à SCHED_OTHER.

       –  Si  le processus appelant a une valeur de politesse négative, elle est mise à zéro pour
          les processus enfant.

       Une fois que l'attribut reset-on-fork est activé, il ne peut  être  désactivé  que  si  le
       thread  possède  la  capacité  CAP_SYS_NICE. Cet attribut est désactivé pour les processus
       enfant créés avec fork(2).

   Privilèges et limites de ressources
       Avec les noyaux Linux antérieurs à 2.6.12, seuls les  threads  privilégiés  (CAP_SYS_NICE)
       pouvaient  attribuer  une  priorité statique non nulle (c'est-à-dire définir une politique
       d'ordonnancement temps réel). Le seul changement qu'un thread non privilégié pouvait faire
       était  d'affecter  la  politique  SCHED_OTHER  et  cela  ne pouvait être fait que si l'UID
       effectif de l'appelant  était  le  même  que  l'UID  réel  ou  effectif  du  thread  cible
       (c'est-à-dire le thread spécifié par pid) dont la politique était modifiée.

       Un  thread  doit  avoir  des  droits  spécifiques  (CAP_SYS_NICE) pour pouvoir affecter ou
       modifier la politique SCHED_DEADLINE.

       Depuis Linux 2.6.12, la limite de ressources RLIMIT_RTPRIO  définit  un  plafond  pour  la
       priorité  statique  d'un thread non privilégié pour les politiques SCHED_RR et SCHED_FIFO.
       Les règles pour modifier la politique d'ordonnancement et la priorité sont les suivantes :

       –  Si un thread non privilégié a une  limite  souple  RLIMIT_RTPRIO  non  nulle,  il  peut
          modifier  sa  politique  et  sa  priorité d'ordonnancement, à condition que la priorité
          reste  inférieure  au  maximum  de  sa  priorité  actuelle  et  à  sa   limite   souple
          RLIMIT_RTPRIO.

       –  Si la limite souple RLIMIT_RTPRIO est nulle, les seules modifications permises sont une
          diminution de la priorité ou bien un basculement vers une politique qui n'est pas temps
          réel.

       –  Soumis  aux  mêmes  règles,  un  autre  thread  non privilégié peut également faire ces
          modifications à partir du moment où l'UID effectif du thread effectuant la modification
          correspond à l'UID réel ou effectif du thread cible.

       –  Des  règles particulières s'appliquent à la politique SCHED_IDLE. Dans les noyaux Linux
          antérieurs à 2.6.39, un thread non privilégié opérant sous cette politique ne peut  pas
          modifier  sa  politique,  quelle  que  soit la valeur de sa limite souple de ressources
          RLIMIT_RTPRIO. Dans les noyaux Linux postérieurs à 2.6.39,  un  thread  non  privilégié
          peut  basculer  vers  la  politique  SCHED_BATCH  ou  SCHED_OTHER tant que sa valeur de
          politesse tombe dans l'intervalle  permis  par  sa  limite  de  ressources  RLIMIT_NICE
          (consultez getrlimit(2)).

       Les  threads  privilégiés  (CAP_SYS_NICE)  ignorent  la  limite RLIMIT_RTPRIO : comme avec
       d'anciens noyaux, ils peuvent modifier arbitrairement la politique d'ordonnancement et  la
       priorité. Consultez getrlimit(2) pour plus d'informations sur RLIMIT_RTPRIO.

   Limiter l'utilisation CPU des processus temps-réel et à échéances.
       Une  boucle  sans  fin  non  bloquante  dans  un  thread  ordonnancé  selon  une politique
       SCHED_FIFO, SCHED_RR ou SCHED_DEADLINE peut potentiellement bloquer  indéfiniment  l’accès
       au  CPU  de  tous  les threads. Avant Linux 2.6.25, le seul moyen d'éviter qu'un processus
       temps réel hors de contrôle ne bloque le système était  d'exécuter  (sur  la  console)  un
       shell  ayant  un  priorité  statique  supérieure  à  celle  de  l'application testée. Cela
       permettait d'exécuter en urgence une commande kill sur  les  applications  temps  réel  en
       cours de test qui ne se bloquaient pas ou ne se terminaient pas comme prévu.

       Depuis Linux 2.6.25, il existe d'autres techniques pour traiter le cas des processus temps
       réel et à échéances qui sont hors de contrôle. L'une de ces techniques consiste à utiliser
       la  limite de ressources RLIMIT_RTTIME pour définir la limite du temps CPU qu'un processus
       temps réel a le droit de consommer. Consultez getrlimit(2) pour plus de détails.

       Depuis la version 2.6.25, Linux propose également deux fichiers  /proc  qui  peuvent  être
       utilisés pour réserver une certaine quantité de temps CPU aux processus non temps réel. La
       réservation de temps CPU par ce moyen permet d'allouer du temps CPU,  par  exemple,  à  un
       shell administrateur pour qu'il puisse exécuter une commande kill sur un processus hors de
       contrôle. Ces deux fichiers définissent des valeurs exprimées en microseconde :

       /proc/sys/kernel/sched_rt_period_us
              Ce fichier définit une période d'ordonnancement correspondant à 100 % de  la  bande
              passante du CPU. La valeur contenue dans ce fichier peut aller de 1 à INT_MAX, soit
              une durée allant de 1 microseconde à  environ  35 minutes.  La  valeur  par  défaut
              contenue dans ce fichier est 1 000 000 (1 seconde).

       /proc/sys/kernel/sched_rt_runtime_us
              La  valeur contenue dans ce fichier définit quelle part d'une « période » peut être
              utilisée par des processus temps réel et à échéances. La valeur  contenue  dans  ce
              fichier  peut  aller  de  −1  à  INT_MAX −1. −1 fixe un temps d'exécution égal à la
              période, c'est à dire qu'aucun temps CPU n'est réservé pour les processus non temps
              réel (ce qui correspond au comportement de Linux avant la version 2.6.25 du noyau).
              La valeur par défaut contenue dans ce fichier est 950 000  (0,95 seconde),  ce  qui
              signifie  que  5 %  du  temps  CPU est réservé aux processus qui ne s'exécutent pas
              selon une politique d'ordonnancement temps réel ou à échéances.

   Temps de réponse
       Un thread de haute priorité bloqué en attente d'entrées-sorties est affecté  d'un  certain
       temps  de  réponse  avant d'être sélectionné à nouveau. Le concepteur d'un gestionnaire de
       périphérique peut réduire grandement ce temps de  réponse  en  utilisant  un  gestionnaire
       d'interruptions « lentes ».

   Divers
       Les  processus enfant héritent de la politique d'ordonnancement et des paramètres associés
       lors d'un fork(2). La politique et  les  paramètres  d'ordonnancement  sont  conservés  au
       travers d'un execve(2).

       Le  verrouillage  de pages en mémoire est généralement nécessaire pour les processus temps
       réel afin d'éviter les délais de pagination ; cela peut être  effectué  avec  mlock(2)  ou
       mlockall(2).

   Fonctionnalité d’autogroupage
       Depuis  Linux 2.6.38, le noyau fournit une fonctionnalité connue comme l’autogroupage pour
       améliorer les performances des bureaux interactifs confrontés à  des  charges  de  travail
       multiprocessus  utilisant énormément le CPU telles que la construction du noyau Linux avec
       un grand nombre de processus de construction en parallèle (c’est-à-dire l’indicateur -j de
       make(1)).

       Cette  fonction  opère  en  conjonction  avec  l’ordonnancement  CFS et nécessite un noyau
       configuré  avec  CONFIG_SCHED_AUTOGROUP.  Sur  un  système  en  cours  d’exécution,  cette
       fonctionnalité     est     activée     ou     désactivée     à     l’aide    du    fichier
       /proc/sys/kernel/sched_autogroup_enabled.  Une  valeur 0  désactive  cette  fonctionnalité
       tandis qu’une valeur 1 l’active. La valeur par défaut dans ce fichier est 1 à moins que le
       noyau ait été amorcé avec le paramètre noautogroup.

       Un nouvel autogroupe est créé quand une nouvelle session est créée à l’aide de  setsid(2).
       Cela  se  produit,  par  exemple,  quand une nouvelle fenêtre de terminal est démarrée. Un
       nouveau processus créé par fork(2) hérite de l’appartenance d’autogroupe  de  son  parent.
       Par  conséquent,  tous  les processus dans une session sont membres du même autogroupe. Un
       autogroupe est automatiquement détruit quand le dernier processus du groupe se termine.

       Lorsque l’autogroupage est activé, tous les membres d’un autogroupe sont  placés  dans  le
       même  ordonnanceur « groupe de tâches » du noyau. L’ordonnanceur CFS emploie un algorithme
       qui égalise la distribution des cycles du CPU entre les groupes de tâches. Le bénéfice qui
       en découle pour la performance de bureau interactif peut être décrit à l’aide de l’exemple
       qui suit.

       Supposons qu’il existe deux autogroupes en compétition pour le même CPU (c’est-à-dire soit
       un  système  avec  un  seul  CPU,  soit l’utilisation de taskset(1) pour confiner tous les
       processus sur le même CPU sur un système SMP). Le premier groupe  contient  dix  processus
       liés à un CPU d’une construction de noyau démarrée avec make -j10. L’autre groupe contient
       un seul processus lié à un CPU : un lecteur vidéo. Le résultat de l’autogroupage  est  que
       les  deux  groupes  recevront chacun la moitié des cycles CPU. C’est-à-dire que le lecteur
       vidéo recevra 50 % des cycles CPU, plutôt que seulement 9 % des cycles, ce qui  conduirait
       probablement  à  une  lecture  vidéo  dégradée.  La  situation sur le système SMP est plus
       complexe, mais l’effet général est le même : l’ordonnanceur répartit les cycles  CPU  dans
       les  groupes  de  tâches  de  telle  façon  qu’un  autogroupe contenant un grand nombre de
       processus liés à un CPU n’aboutisse pas à un accaparement des cycles CPU au détriment  des
       autres travaux dans le système.

       L’appartenance  à  un  autogroupe  de  processus  (groupe de tâches) peut être vue dans le
       fichier /proc/[pid]/autogroup:

           $ cat /proc/1/autogroup
           /autogroup-1 nice 0

       Ce fichier peut aussi être utilisé pour modifier la bande passante de  CPU  allouée  à  un
       autogroupe. Cela peut être réalisé en écrivant un nombre dans le champ « nice » du fichier
       pour définir la valeur de politesse de  l’autogroupe.  L’intervalle  autorisé  va  de  +19
       (priorité  basse)  à  -20  (priorité  haute).  L’écriture  d’une  valeur  en dehors de cet
       intervalle provoquera l’échec de write(2) avec l’erreur EINVAL.

       Le réglage de la politesse de l’autogroupe a la même acception que la valeur de  politesse
       du  processus,  mais  s’applique  à la répartition des cycles CPU à un autogroupe dans son
       ensemble, basée sur les valeurs relatives de politesse des  autres  autogroupes.  Pour  un
       processus  dans  un  autogroupe,  les cycles CPU qu’il reçoit sont déduits de la valeur de
       politesse de l’autogroupe (comparée aux autres autogroupes) et de la valeur  de  politesse
       du processus (comparée aux autres processus dans le même autogroupe).

       L’utilisation  du  contrôleur de CPU cgroups(7) pour placer les processus dans des cgroups
       autres que le cgroup racine du CPU contourne l’effet de l’autogroupage.

       La fonctionnalité d’autogroupage groupe seulement  les  processus  ordonnancés  selon  des
       politiques non temps réel (SCHED_OTHER, SCHED_BATCH et SCHED_IDLE). Elle ne groupe pas les
       processus ordonnancés selon les  politiques  temps  réel  et  à  échéances.  Ceux-ci  sont
       ordonnancés selon les règles décrites ci-dessus.

   Valeur de politesse et ordonnancement de groupe
       Lors  de l’ordonnancement de processus non temps réel (c’est-à-dire ceux ordonnancés selon
       les politiques SCHED_OTHER, SCHED_BATCH et SCHED_IDLE),  L’ordonnanceur  CFS  emploie  une
       technique  connue  comme « ordonnancement de groupe » (group scheduling) si le noyau a été
       configuré avec l’option CONFIG_FAIR_GROUP_SCHED (ce qui est typique).

       Avec l’ordonnancement de groupe, les  threads  sont  ordonnancés  dans  des  « groupes  de
       tâches ».  Celles-ci  ont une relation hiérarchique, avec comme racine le groupe de tâches
       initial du système connu comme « groupe de tâches racine » (root task group). Les  groupes
       de tâches sont constitués dans les circonstances suivantes :

       –  Tous  les  threads  dans  un cgroup du CPU forment un groupe de tâches. Le parent de ce
          groupe de tâches est le groupe de tâches du cgroup parent correspondant.

       –  Si l’autogroupage est activé, alors tous les threads qui  sont  (implicitement)  placés
          dans  un  autogroupe  (c’est-à-dire  la  même  session,  telle que créée par setsid(2))
          forment un groupe de tâches. Chaque nouvel autogroupe est par conséquent un  groupe  de
          tâches distinct. Le groupe de tâches racine est le parent de tous les autogroupes de ce
          type.

       –  Si l’autogroupage est activé, alors le groupe de tâches racine se compose de  tous  les
          processus  dans  le  cgroup  racine  du  CPU  qui  n’étaient  pas  par  ailleurs placés
          implicitement dans un nouvel autogroupe.

       –  Si l’autogroupage est désactivé, alors le groupe de tâches racine est constitué de tous
          les processus dans le cgroup racine du CPU.

       –  Si  l’ordonnancement  de  groupe  a  été  désactivé  (c’est-à-dire  que  le noyau a été
          configuré sans CONFIG_FAIR_GROUP_SCHED), alors tous les processus du  système  sont  en
          théorie placés dans un groupe de tâches unique.

       Avec  l’ordonnancement  de  groupe,  une  valeur de politesse de thread a un effet sur les
       décisions d’ordonnancement seulement relatives aux autres threads dans le même  groupe  de
       tâches. Cela a quelques conséquences surprenantes en terme de sémantique traditionnelle de
       la valeur de politesse sur les systèmes UNIX. En particulier, si l’autogroupage est activé
       (par  défaut dans diverses distributions), alors l’emploi de setpriority(2) ou nice(1) sur
       un processus a un effet seulement sur l’ordonnancement  concernant  les  autres  processus
       exécutés dans la même session (classiquement : la même fenêtre de terminal).

       Inversement,  pour deux processus qui sont (par exemple) les seuls processus liés à un CPU
       dans différentes sessions (par exemple, des fenêtres distinctes de terminal,  chacune  des
       tâches  étant liée à un autogroupe distinct), modifier la valeur de politesse du processus
       d’une des sessions n’a pas d’effet en  terme  de  décision  d’ordonnancement  relative  au
       processus  dans  l’autre  session. Un contournement utile possible consiste à utiliser une
       commande telle que la suivante pour modifier la valeur de politesse de  l’autogroupe  pour
       tous les processus dans une session de terminal :

           $ echo 10 > /proc/self/autogroup

   Fonctionnalités temps réel dans le noyau Linux principal
       Depuis  le  noyau 2.6.18,  Linux  a  été  graduellement pourvu de capacités temps réel, la
       plupart étant dérivées de l’ancien ensemble de greffons realtime-preempt. Jusqu'à  ce  que
       ces  greffons  aient  été  entièrement fusionnés dans le noyau principal, ils devront être
       installés  pour  atteindre  les  meilleures  performances   temps   réel.   Ces   greffons
       s'appellent :

           patch-version-noyau-rtversion-greffon

       et  peuvent  être téléchargés à partir de ⟨http://www.kernel.org/pub/linux/kernel/projects
       /rt/⟩.

       Sans  les  greffons  et  avant  leur  complète  inclusion  dans  le  noyau  principal,  la
       configuration  du  noyau  n'offre  que  trois  classes  de préemption CONFIG_PREEMPT_NONE,
       CONFIG_PREEMPT_VOLUNTARY  et   CONFIG_PREEMPT_DESKTOP   qui   fournissent   respectivement
       « aucune »,   « quelque »   et   une   « considérable »   réduction  de  la  pire  latence
       d'ordonnancement.

       Avec les greffons appliqués ou après leur pleine inclusion dans  le  noyau  principal,  la
       configuration  supplémentaire  CONFIG_PREEMPT_RT  devient disponible. Si elle est choisie,
       Linux est transformé en un système d'exploitation temps  réel  ordinaire.  Les  politiques
       d'ordonnancement  FIFO  et  RR  sont  alors utilisées pour lancer un thread avec une vraie
       priorité temps réel et une latence minimale d'ordonnancement de pire cas.

NOTES

       Le contrôleur cgroups(7) de CPU peut être utilisé pour limiter la consommation de CPU  par
       les groupes de processus.

       À  l'origine,  le  noyau  Linux  standard  visait  un  système  d'exploitation  à vocation
       généraliste, devant gérer des processus en arrière-plan, des applications interactives  et
       des  applications  en  temps  réel  souples  (qui  ont besoin en général de répondre à des
       critères de temps maximal). Bien que le noyau Linux 2.6 ait permis la  préemption  par  le
       noyau  et  que l'ordonnanceur O(1), nouvellement introduit, assure que le temps nécessaire
       pour planifier soit fixé et déterministe quel que soit le  nombre  de  tâches,  une  vraie
       gestion temps réel n'était pas possible avant le noyau 2.6.17.

VOIR AUSSI

       chcpu(1), chrt(1), lscpu(1), ps(1), taskset(1), top(1), getpriority(2), mlock(2),
       mlockall(2), munlock(2), munlockall(2), nice(2), sched_get_priority_max(2),
       sched_get_priority_min(2), sched_getaffinity(2), sched_getparam(2), sched_getscheduler(2),
       sched_rr_get_interval(2), sched_setaffinity(2), sched_setparam(2), sched_setscheduler(2),
       sched_yield(2), setpriority(2), pthread_getaffinity_np(3), pthread_getschedparam(3),
       pthread_setaffinity_np(3), sched_getcpu(3), capabilities(7), cpuset(7)

       Programming for the real world  POSIX.4 de Bill O. Gallmeister,  O'Reilly  &  Associates,
       Inc., ISBN 1-56592-074-0.

       Les   fichiers   source   du   noyau   Linux   Documentation/scheduler/sched-deadline.txt,
       Documentation/scheduler/sched-rt-group.txt,   Documentation/scheduler/sched-design-CFS.txt
       et Documentation/scheduler/sched-nice-design.txt

COLOPHON

       Cette  page  fait partie de la publication 5.10 du projet man-pages Linux. Une description
       du projet et des instructions pour signaler des anomalies et la dernière version de  cette
       page peuvent être trouvées à l'adresse https://www.kernel.org/doc/man-pages/.

TRADUCTION

       La  traduction  française  de  cette  page  de  manuel  a  été créée par Christophe Blaess
       <https://www.blaess.fr/christophe/>, Stéphan  Rafin  <stephan.rafin@laposte.net>,  Thierry
       Vignaud  <tvignaud@mandriva.com>,  François Micaux, Alain Portal <aportal@univ-montp2.fr>,
       Jean-Philippe   Guérard   <fevrier@tigreraye.org>,   Jean-Luc   Coulon   (f5ibh)    <jean-
       luc.coulon@wanadoo.fr>,    Julien    Cristau    <jcristau@debian.org>,    Thomas   Huriaux
       <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
       Duneau  <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis
       Barbier  <barbier@debian.org>,  David  Prévot   <david@tilapin.org>,   Cédric   Boutillier
       <cedric.boutillier@gmail.com>,   Frédéric   Hantrais  <fhantrais@gmail.com>  et  Jean-Paul
       Guillonneau <guillonneau.jeanpaul@free.fr>

       Cette traduction est une documentation libre ; veuillez vous reporter  à  la  GNU  General
       Public   License   version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩  concernant  les
       conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
       message à debian-l10n-french@lists.debian.org ⟨⟩.