Provided by: manpages-fr-dev_3.65d1p1-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.65 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> ».