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