Loading

NOM

       sched_setscheduler,   sched_getscheduler   -  Lire/fixer  la  politique
       d’ordonnancement et ses paramètres

SYNOPSIS

       #include <sched.h>

       int sched_setscheduler(pid_t pid, int policy,
                              const struct sched_param *param);

       int sched_getscheduler(pid_t pid);

       struct sched_param {
           ...
           int sched_priority;
           ...
       };

       sched_setscheduler() fixe à la fois la  politique  d’ordonnancement  et
       ses  paramètres  pour  le  processus dont l’identifiant est indiqué par
       pid. Si pid vaut zéro, la politique d’ordonnancement et ses  paramètres
       pour  le  processus  en cours sera fixée. L’interprétation du paramètre
       param dépend de la politique  employée.  Actuellement,  les  politiques
       normales  (c’est-à-dire  non  temps  réel) proposées par Linux sont les
       suivantes :

       SCHED_OTHER   politique standard de temps partagé « round-robin » :

       SCHED_BATCH   pour une  exécution  de  style  traitement  par  lot  des
                     processus ; et

       SCHED_IDLE    pour  l’exécution  de  tâches  de trs faible priorité en
                     arrière-plan.

       Les politiques temps réel suivantes sont  également  gérées,  pour  des
       applications  particulières  sensibles  au  temps  qui  nécessitent  un
       contrôle précis sur la façon  dont  sont  choisis  pour  exécution  les
       processus exécutables :

       SCHED_FIFO    une politique de « premier entré, premier sorti » ; et

       SCHED_RR      une politique « round-robin ».

       La sémantique de chacune de ces politiques est décrite ci-dessous.

       sched_getscheduler()   lit   la   politique   d’ordonnancement  et  ses
       paramètres pour le processus identifié par pid. Si pid  vaut  zéro,  la
       politique du processus en cours sera renvoyée.

   Politiques dordonnancement
       L’ordonnanceur est la partie du noyau qui décide quel processus prêt va
       être exécuté ensuite. Chaque processus a une politique d’ordonnancement
       associée et une priorité d’ordonnancement statique, sched_priority ; ce
       sont les réglages  modifiés  par  sched_setscheduler().  L’ordonnanceur
       prend  ses décisions en fonction de la politique d’ordonnancement et de
       la priorité statique de tous les processus du système.

       Pour   les   processus   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 de sched_priority dans
       l’intervalle  1 (faible) à 99 (haute). (Comme les nombres l’impliquent,
       les processus temps réel ont toujours une priorité plus haute  que  les
       processus   normaux.)   Notez  bien :  POSIX.1-2001  ne  réclame  d’une
       implémentation qu’elle gère  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.

       Conceptuellement,  l’ordonnanceur  dispose  d’une  liste  de  tous  les
       processus  prêts 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 processus en tête de cette liste.

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

       Tout ordonnancement est préemptif : si un processus avec  une  priorité
       statique  plus  élevée devient prêt, le processus 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
       simplement l’ordre utilisé dans une liste de processus prêts  avec  des
       priorités statiques égales.

   SCHED_FIFO :  Ordonnancement  First  In-First  Out (premier arrivé, premier
       servi)
       SCHED_FIFO ne  peut  être  utilisée  qu’avec  des  priorités  statiques
       supérieures  à  0,  ce  qui signifie que dès qu’un processus SCHED_FIFO
       devient  prêt,  un  processus  normal   SCHED_OTHER,   SCHED_BATCH   ou
       SCHED_IDLE  en  cours  d’exécution  sera  interrompu. SCHED_FIFO est un
       ordonnancement simple  sans  tranches  de  temps.  Pour  les  processus
       ordonnancés par SCHED_FIFO les règles suivantes sont appliquées :

       *  Un processus SCHED_FIFO qui a été préempté par un autre processus de
          priorité supérieure restera en tête de sa  liste  et  reprendra  son
          exécution dès que tous les processus de priorités supérieures sont à
          nouveau bloqués.

       *  Quand un processus SCHED_FIFO devient prêt, il est inséré à  la  fin
          de sa liste.

       *  Un  appel  système sched_setscheduler() ou sched_setparam(2) placera
          le processus SCHED_FIFO (ou SCHED_RR) identifié par pid en  tête  de
          sa liste s’il est prêt. Il pourra donc stopper le processus en cours
          d’exécution si  sa  priorité  est  au  moins  aussi  grande.  (Selon
          POSIX.1-2001, le processus devrait aller à la fin de sa liste.)

       *  Un  processus  appelant  sched_yield(2)  sera  placé  à la fin de sa
          liste.

       Aucun autre événement ne modifiera  l’ordre  des  listes  de  priorités
       statiques égales avec SCHED_FIFO.

       Un  processus SCHED_FIFO s’exécute jusqu’à ce qu’il soit bloqué par une
       opération d’entrée-sortie, qu’il soit  préempté  par  un  processus  de
       priorité supérieure, ou qu’il appelle sched_yield(2).

   SCHED_RR : Ordonnancement Round Robin
       SCHED_RR  est  une amélioration simple de la politique SCHED_FIFO. Tout
       ce qui est décrit pour SCHED_FIFO s’applique aussi à SCHED_RR, sauf que
       chaque  processus  ne dispose que d’une tranche temporelle limitée pour
       son exécution. Si un processus sous politique  SCHED_RR  s’est  exécuté
       depuis  une  durée  supérieure  ou  égale à la tranche temporelle (time
       quantum), il sera placé à la  fin  de  la  liste  de  sa  priorité.  Un
       processus sous SCHED_RR qui a été préempté par un processus de priorité
       supérieure terminera  sa  tranche  de  temps  lorsqu’il  reprendra  son
       exécution.  La  longueur  du  quantum  de  temps  peut  être  lue  avec
       sched_rr_get_interval(2).

   SCHED_OTHER : Ordonnancement tempspartagé par défaut
       La politique SCHED_OTHER ne peut être utilisée  qu’avec  des  priorités
       statiques  à  0.  C’est  la  politique standard de l’ordonnanceur temps
       partagé de Linux, et est conçue pour tous les  processus  ne  réclamant
       pas  de  fonctionnalités temps-réel. Le processus à exécuter est choisi
       dans la liste des processus de priorités statiques nulles, en utilisant
       une  priorité  dynamique  qui  ne  s’applique  que dans cette liste. La
       priorité  dynamique  est  basée  sur  la  valeur  de  « politesse »  du
       processus  (fixée avec les appels système nice(2) ou setpriority(2)) et
       est incrémentée à chaque quantum de temps où le processus est prêt mais
       non  sélectionné  par  l’ordonnanceur.  Ceci  garantit  une progression
       équitable de tous les processus SCHED_OTHER.

   SCHED_BATCH : Ordonnancement de processus de traitement 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  processus  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
       processus demande beaucoup de ressources processeur. Par conséquent, il
       lui appliquera une pénalité d’ordonnancement vis-à-vis du  comportement
       au  réveil,  et  le  processus  sera  légèrement  désavantagé  dans les
       décisions d’ordonnancement.

       Cette politique est utile pour les processus non interactifs, mais  qui
       ne  souhaitent  pas diminuer leur valeur de politesse, ou pour ceux qui
       veulent  une  politique   d’ordonnancement   déterministe,   sans   que
       l’interactivité ne cause de préemptions supplémentaires.

   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 courtoisie  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  courtoisie  +19  dans  les
       politiques SCHED_OTHER ou SCHED_BATCH).

   Privilèges et limites de ressources
       Avec  les  noyaux  Linux  antérieurs  à  2.6.12,  seuls  les  processus
       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 processus non privilégié pouvait  faire
       était  d’affecter  la  politique  SCHED_OTHER,  et  seulement  si l’UID
       effectif de l’appelant de sched_setscheduler() était le même que  l’UID
       réel ou effectif du processus cible (c’est-à-dire le processus spécifié
       par pid), dont la politique est modifiée.

       Depuis Linux 2.6.12, la limite de ressources RLIMIT_RTPRIO  définit  un
       plafond  pour  la  priorité statique d’un processus 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 processus 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 à la 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 ne soit pas temps réel.

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

       * Des règles particulières s’appliquent à SCHED_IDLE : un processus 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.

       Les   processus   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é.  Voir
       getrlimit(2) pour plus d’informations sur RLIMIT_RTPRIO.

   Temps de réponse
       Un  processus 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  fils  héritent  de la politique d’ordonnancement et des
       paramètres associés lors d’un fork(2). L’algorithme 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 ;  ceci
       peut être effectué avec mlock(2) ou mlockall(2).

       Comme  une  boucle  sans fin non bloquante dans un processus ordonnancé
       sous une politique SCHED_FIFO ou SCHED_RR  bloquera  indéfiniment  tous
       les   processus   avec   une   priorité  plus  faible,  le  développeur
       d’applications temps‐réel devrait toujours conserver sur une console un
       shell  ordonnancé avec une priorité supérieure à celle de l’application
       testée. Ceci permettra un kill(1) d’urgence  des  applications  testées
       qui  ne  se  bloquent  pas ou qui ne se terminent pas comme prévu. Voir
       également la description de la limite de ressources RLIMIT_RTTIME  dans
       getrlimit(2).

       Les    systèmes    POSIX    sur    lesquels   sched_setscheduler()   et
       sched_getscheduler()        sont        disponibles         définissent
       _POSIX_PRIORITY_SCHEDULING dans <unistd.h>.

VALEUR RENVOYÉE

       sched_setscheduler()   renvoie  0  s’il  réussit.  sched_getscheduler()
       renvoie la politique pour le processus (un entier >= 0)  s’il  réussit.
       En cas d’échec, -1 est renvoyé et errno contient le code d’erreur.

ERREURS

       EINVAL La  valeur de politique d’ordonnancement policy n’existe pas, ou
              param n’a pas de signification pour la politique policy.

       EPERM  Le processus appelant ne possède pas les privilèges nécessaires.

       ESRCH  Le processus numéro pid n’existe pas.

CONFORMITÉ

       POSIX.1-2001  (voir  la  section  BOGUES  ci-dessous).  Les  politiques
       SCHED_BATCH et SCHED_IDLE sont spécifiques à Linux.

NOTES

       POSIX.1 ne détaille pas quelles permissions sont nécessaire pour  qu’un
       processus  non  privilégié  puisse appeler sched_setscheduler(), et les
       détails dépendent des systèmes. Par  exemple,  la  page  de  manuel  de
       Solaris  7  dit  que  l’UID réel ou effectif du processus appelant doit
       correspondre à l’UID réel ou sauvé du processus visé.

       À 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  souple
       (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 du noyau
       et  que le nouvellement introduit ordonnanceur O(1) assure que le temps
       nécessaire pour planifier soit fixe 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.

   Fonctionalités temps réel dans le noyau Linux principal
       Toutefois, depuis le noyau 2.6.18, Linux s’est vu graduellement  équipé
       de  possibilités  temps  réel,  la plupart étant dérivées des ajouts de
       préemption temps réel  (realtime-preempt)  réalisés  par  Ingo  Molnar,
       Thomas  Gleixner,  Steven  Rostedt et autres. Jusqu’à ce que ces ajouts
       aient été entièrement fusionnés dans le noyau principal (c’est  attendu
       aux  alentours  des  versions  2.6.30), ils doivent être installés pour
       atteindre  les  meilleures  performances   temps   réel.   Ces   ajouts
       s’appellent :

           patch-version-noyau-rtversion-patch

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

       Sans les  ajouts  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  fournissement  respectivement  « aucune »,
       « quelque »  et  une   « considérable »   réduction   de   la   latence
       d’ordonnancement de pire cas.

       Avec  les ajouts 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  qui  peuvent être définies avec sched_setscheduler() sont
       alors utilisées pour lancer un processus avec une vraie priorité  temps
       réel et une latence minimum d’ordonnancement de pire cas.

BOGUES

       POSIX  dit qu’en cas de réussite, sched_setscheduler() devrait renvoyer
       la  politique  d’ordonnancement  précédente.  La   version   Linux   de
       sched_setscheduler()  ne  se  conforme  par à cette demande puisqu’elle
       renvoie toujours 0 en cas de réussite.

VOIR AUSSI

       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_rr_get_interval(2),
       sched_setaffinity(2),         sched_setparam(2),        sched_yield(2),
       setpriority(2), capabilities(7), cpuset(7)

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

       Le  fichier Documentation/scheduler/sched-rt-group.txt dans les sources
       du noyau (depuis le noyau 2.6.25).

COLOPHON

       Cette page fait partie de  la  publication  3.23  du  projet  man-pages
       Linux.  Une description du projet et des instructions pour signaler des
       anomalies      peuvent      être       trouvées       à       l’adresse
       http://www.kernel.org/doc/man-pages/.

TRADUCTION

       Cette  page  de  manuel  a  été  traduite et mise à jour par Christophe
       Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis  par
       Alain  Portal  <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et mise à
       disposition sur http://manpagesfr.free.fr/.

       Les mises à jour et corrections de la version présente dans Debian sont
       directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
       francophone de traduction de Debian.

       Veuillez  signaler  toute  erreur   de   traduction   en   écrivant   à
       <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
       paquet manpages-fr.

       Vous pouvez toujours avoir accès à la version anglaise de  ce  document
       en utilisant la commande « man -L C <section> <page_de_man> ».