Provided by: manpages-fr-dev_3.32d0.2p4-1_all bug

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;
           ...
       };

DESCRIPTION

       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 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 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 d'ordonnancement
       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 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 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).

   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 processus 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  processus  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 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é. Consultez 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. 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  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, param vaut NULL ou 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.32 du projet man-pages Linux. Une description
       du projet et des  instructions  pour  signaler  des  anomalies  peuvent  être  trouvées  à
       l'adresse <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

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

       Christophe   Blaess   <URL:http://www.blaess.fr/christophe/>   (1996-2003),  Alain  Portal
       <URL: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> ».