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