Provided by: manpages-fr-dev_3.57d1p1-1_all bug

NOM

       sched_setscheduler,  sched_getscheduler - Lire et définir 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;
           ...
       };

DESCRIPTION

       sched_setscheduler() définit à la fois la politique  d'ordonnancement  et  ses  paramètres
       pour  le  thread  dont  l'identifiant  est indiqué par pid. Si pid vaut zéro, la politique
       d'ordonnancement  et  ses  paramètres  pour   le   thread   en   cours   seront   définis.
       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 très 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 threads 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  thread
       identifié par pid. Si pid vaut zéro, la politique du thread en cours sera renvoyée.

   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 ;   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 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 de 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-2001  exige  seulement  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 threads 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 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 simplement l'ordre utilisé dans une liste de threads 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 thread SCHED_FIFO  devient  prêt,  un  thread  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 threads ordonnancés par  SCHED_FIFO
       les règles suivantes sont appliquées :

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

       *  Quand un thread 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 thread SCHED_FIFO
          (ou SCHED_RR) identifié par pid en tête de sa liste  s'il  est  prêt.  Il  pourra  donc
          stopper le thread en cours d'exécution si sa priorité est au moins aussi grande. (Selon
          POSIX.1-2001, le thread devrait aller à la fin de sa liste.)

       *  Un thread 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   thread   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  thread  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 thread ne dispose  que  d'une
       tranche  temporelle limitée pour son exécution. Si un thread 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 thread sous SCHED_RR qui a été préempté
       par un thread 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 temps‐partagé 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 thread ne réclamant pas de fonctionnalités temps-réel. Le thread à exécuter est choisi
       dans la liste des threads  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  thread  (définie  avec  les  appels  système   nice(2)   ou
       setpriority(2))  et  est  incrémentée à chaque quantum de temps où le thread est prêt mais
       non sélectionné par l'ordonnanceur. Ceci garantit une progression équitable  de  tous  les
       thread 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  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 pénalité
       d'ordonnancement vis-à-vis du  comportement  au  réveil,  et  le  thread  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).

   Réinitialiser la politique d'ordonnancement pour les processus fils
       Depuis  Linux  2.6.32,  l'attribut  SCHED_RESET_ON_FORK  peut être inclus à l'aide d'un OU
       binaire dans policy dans l'appel à sched_setscheduler(). Avec cet attribut, les fils créés
       par   fork(2)   n'héritent   pas   de   politiques  d'ordonnancement  privilégiées.  Cette
       fonctionnalité 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 fils.

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

       *  Si  le  thread  appelant  a  une  politique d'ordonnancement SCHED_FIFO ou SCHED_RR, la
          politique pour les processus fils 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 fils.

       Une  fois  que l'attribut SCHED_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
       fils créés avec fork(2).

       L'attribut  SCHED_RESET_ON_FORK  est  visible  dans la valeur de la politique du processus
       renvoyée par sched_getscheduler()

   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 seulement si l'UID effectif de l'appelant de
       sched_setscheduler()  é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 est modifiée.

       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  à  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  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 à 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_NORMAL 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.

   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 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  thread  ordonnancé  sous  une  politique
       SCHED_FIFO  ou  SCHED_RR  bloquera  indéfiniment  tous  les threads 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.  Consultez  é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 thread (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, param vaut NULL ou n'a
              pas de signification pour la politique policy.

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

       ESRCH  Le thread 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 thread 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 thread appelant
       doit correspondre à l'UID réel ou sauvé du processus visé.

       Sous Linux, la politique et les  paramètres  d'ordonnancement  sont,   des  attributs  des
       threads.  La valeur renvoyée par un appel à gettid(2) peut être passée via l'argument pid.
       Lorsque la valeur de pid indiquée est 0, l'attribut sera défini pour le thread  appelant ;
       lorsque  cette  valeur  est celle renvoyée par getpid(2), l'attribut modifié sera celui du
       thread principal du groupe de threads (si vous utilisez l'API de manipulation des  threads
       POSIX,    alors    utilisez    pthread_setschedparam(3),    pthread_getschedparam(3)    et
       pthread_setschedprio(3) plutôt que les appels système sched_*(2)).

       À 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.

   Fonctionnalité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 thread 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

       chrt(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_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 des sources du noyau Linux Documentation/scheduler/sched-rt-group.txt

COLOPHON

       Cette  page  fait partie de la publication 3.57 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

       Depuis    2010,    cette   traduction   est   maintenue   à   l'aide   de   l'outil   po4a
       <http://po4a.alioth.debian.org/> par l'équipe de traduction francophone au sein du  projet
       perkamon <http://perkamon.alioth.debian.org/>.

       Christophe    Blaess    <http://www.blaess.fr/christophe/>   (1996-2003),   Alain   Portal
       <http://manpagesfr.free.fr/>  (2003-2006).  Julien  Cristau  et  l'équipe  francophone  de
       traduction de Debian (2006-2009).

       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> ».