Ubuntu Manpage: sched – Aperçu de l’ordonnancement de CPU

NOM

       sched – Aperçu de l’ordonnancement de CPU

DESCRIPTION

Depuis Linux 2.6.23, l’ordonnanceur par défaut est CFS (Completely Fair Scheduler
– ordonnanceur complètement équitable). Il remplace l’ordonnanceur précédent, « O(1) ».

Résumé des API
Linux fournit les appels système suivants pour contrôler le comportement de
l’ordonnancement du CPU, la politique et la priorité des processus (ou, plus précisément,
des threads).

nice(2)
Définir une nouvelle valeur de politesse pour le thread appelant et renvoyer cette
nouvelle valeur.

getpriority(2)
Renvoyer la valeur de politesse d’un thread, d’un groupe de processus ou de
l’ensemble des threads possédés par un utilisateur particulier.

setpriority(2)
Définir la valeur de politesse d’un thread, d’un groupe de processus ou de
l’ensemble des threads possédés par un utilisateur particulier.

sched_setscheduler(2)
Définir la politique d'ordonnancement et les paramètres du thread indiqué.

sched_getscheduler(2)
Renvoyer la politique d'ordonnancement du thread indiqué.

sched_setparam(2)
Définir les paramètres d'ordonnancement du thread indiqué.

sched_getparam(2)
Récupérer les paramètres d'ordonnancement du thread indiqué.

sched_get_priority_max(2)
Renvoyer la priorité la plus haute disponible pour la politique d'ordonnancement
indiquée.

sched_get_priority_min(2)
Renvoyer la priorité la plus basse disponible pour la politique d'ordonnancement
indiquée.

sched_rr_get_interval(2)
Récupérer le quantum de temps alloué utilisé pour les threads ordonnancés par une
politique de type répartition par tourniquet (round robin).

sched_yield(2)
Provoquer la libération du CPU par l'appelant afin de permettre l’exécution
d'autres threads.

sched_setaffinity(2)
Définir le masque d'affinité CPU du thread indiqué (propre à Linux).

sched_getaffinity(2)
Récupérer le masque d'affinité CPU du thread indiqué (propre à Linux).

sched_setattr(2)
Définir la politique d'ordonnancement et les paramètres du thread indiqué. Cet
appel système (propre à Linux) fournit un sur-ensemble de la fonctionnalité de
sched_setscheduler(2) et de sched_setparam(2).

sched_getattr(2)
Récupérer la politique d'ordonnancement et les paramètres du thread indiqué. Cet
appel système (propre à Linux) fournit un sur-ensemble de la fonctionnalité de
sched_getscheduler(2) et de sched_getparam(2).

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. 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 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 exige d'une implémentation
qu'elle gère seulement 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.

Théoriquement, l'ordonnanceur entretient une liste de tous les threads prêts pour
l’exécution 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 l'ordre utilisé seulement dans la liste de threads prêts avec des priorités
statiques égales.

SCHED_FIFO : Ordonnancement premier entré, premier sorti
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, il préempte n’importe quel thread
SCHED_OTHER, SCHED_BATCH ou SCHED_IDLE en cours d'exécution. SCHED_FIFO est un
ordonnancement simple sans découpage temporel. Pour les threads ordonnancés selon la
politique SCHED_FIFO, les règles suivantes sont appliquées :

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

2) Quand un thread SCHED_FIFO bloqué devient prêt, il est inséré en fin de liste pour sa
priorité.

3) Si un appel à sched_setscheduler(2), sched_setparam(2), sched_setattr(2),
pthread_setschedparam(3) ou pthread_setschedprio(3) modifie la priorité du thread
SCHED_FIFO prêt ou en cours d’exécution, identifié par pid, l’effet sur la position du
thread dans la liste dépend de la direction de la modification de la priorité des
threads :

•
Si la priorité du thread est relevée, il est placé en fin de liste pour sa nouvelle
priorité. Par conséquent, il peut préempter un thread en cours d’exécution ayant la
même priorité.

•
Si la priorité du thread est inchangée, sa position dans la liste des exécutions est
inchangée.

•
Si la priorité du thread est abaissée, il est placé en tête de liste pour sa
nouvelle priorité.

Selon POSIX.1-2008, les modifications de priorité (ou politique) de thread en utilisant
tout autre mécanisme que pthread_setschedprio(3) devraient aboutir à ce que le thread
soit placé en fin de liste pour sa priorité.

4) Un thread appelant sched_yield(2) sera placé en fin liste.

Aucun autre événement ne déplacera un thread ordonnancé selon la politique SCHED_FIFO dans
la liste d’attente des threads prêts de priorité statique équivalente.

Un thread SCHED_FIFO s'exécute jusqu'à ce qu'il soit bloqué par une requête
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 tourniquet
SCHED_RR est une amélioration simple de SCHED_FIFO. Tout ce qui est décrit pour SCHED_FIFO
s'applique aussi à SCHED_RR, sauf que chaque thread ne dispose que d'un quantum de temps
maximal pour son exécution. Si l’exécution d’un thread SCHED_RR est d’une durée supérieure
ou égale au quantum de temps, il sera placé en fin de liste pour sa priorité. Un thread
SCHED_RR qui a été préempté par un thread de priorité supérieure et par conséquent qui
reprend l’exécution en tant que thread en cours, terminera la part non utilisée de son
quantum de temps dans le tourniquet. La valeur du quantum de temps peut être lue avec
sched_rr_get_interval(2).

SCHED_DEADLINE: ordonnancement sur échéances selon le modèle des tâches sporadiques.
Depuis la version 3.14, Linux offre une politique d'ordonnancement sur échéances
(SCHED_DEADLINE). L'implémentation actuelle de cette politique repose sur les algorithmes
GEDF (Global Earliest Deadline First, ou « priorité globale à l'échéance proche ») et CBS
(Constant Bandwidth Server, ou « serveur à bande passante constante ») utilisés
conjointement. Pour définir ou récupérer cette politique et ses attributs associés, les
appels système sched_setattr(2) et sched_getattr(2) doivent être utilisés.

Une tâche sporadique présente une séquence de sous-tâches qui sont chacune activées au
moins une fois par période. Chaque sous-tâche a également une échéance relative, avant
laquelle elle doit achever son exécution, et un temps d'exécution qui est le temps CPU
nécessaire pour qu'elle s'exécute. Le moment auquel une tâche est activée parce qu'une
sous-tâche doit être exécutée est appelé temps d'activation (également désigné temps
d'appel (« request time ») ou temps de libération (« release time »)). Le temps de
lancement est le moment auquel la tâche commence son exécution. L'échéance impérative est
obtenue en additionnant l'échéance relative et le temps d'activation.

Le schéma suivant illustre ces termes :

Lorsqu'une politique SCHED_DEADLINE est activée au moyen de sched_setattr(2), il est
possible de préciser trois paramètres : Runtime, Deadline et Period. Ces paramètres ne
correspondent pas forcément aux termes décrits précédemment : il est d'usage d'affecter à
Runtime une valeur supérieure au temps d'exécution moyen (ou le pire temps d'exécution
possible, pour les cas de temps réel extrêmes) ; Deadline prend la valeur de l'échéance
relative ; enfin, Period reçoit la valeur de la période de la tâche. Ainsi, pour un
ordonnancement SCHED_DEADLINE, on obtient.

Les trois paramètres de configuration de l'ordonnancement sur échéances correspondent aux
champs sched_runtime, sched_deadline et sched_period de la structure sched_attr (consultez
sched_setattr(2)). Ces champs sont exprimés en nanosecondes. Si la valeur 0 est affectée à
sched_period, ce paramètre prend la valeur de sched_deadline.

Le noyau exige que :

sched_runtime <= sched_deadline <= sched_period

De plus, dans l'implémentation actuelle, tous les paramètres doivent valoir au moins 1024
(c'est à dire à peine plus qu'une microseconde, qui est la résolution de cette
implémentation) et moins de 2^63. Si la valeur de l'un de ces paramètres sort de cet
intervalle, sched_setattr(2) échoue en renvoyant l'erreur EINVAL.

Le CBS assure que les différentes tâches n'interfèrent pas en bloquant les threads qui
tentent de dépasser leur temps d'exécution (Runtime).

Pour que les conditions requises par l'ordonnancement sur échéances soient remplies, le
noyau doit empêcher des situations dans lesquelles l’ensemble des threads SCHED_DEADLINE
n’est pas réalisable (ordonnancement non possible) en tenant compte des contraintes
données. Le noyau doit donc exécuter un test d'approbation lorsque la politique
SCHED_DEADLINE et ses attributs sont définis ou modifiés. Ce test d'approbation valide que
le changement demandé est réalisable ; si ce n'est pas le cas, sched_setattr(2) échoue et
renvoie l'erreur EBUSY.

Par exemple, il est nécessaire (et par forcément suffisant) pour l'utilisation totale
d'être inférieure ou égale au nombre total de CPU disponibles, où, puisque chaque thread
peut s'exécuter au plus pour Runtime par Period, l'utilisation pour ce thread vaut son
Runtime divisé par sa Period.

Pour assurer les conditions qui sont requises lorsqu'un thread est autorisé à utiliser la
politique SCHED_DEADLINE, les threads SCHED_DEADLINE ont la priorité la plus élevée parmi
tous les threads (contrôlable par l'utilisateur) du système. Si un thread ordonnancé selon
SCHED_DEADLINE est prêt, il aura la priorité sur tout autre thread ordonnancé par une
autre politique.

Un appel à fork(2) effectué par un thread ordonnancé selon la politique SCHED_DEADLINE
échouera en renvoyant l'erreur EAGAIN, sauf dans le cas ou l'attribut « reset-on-fork » du
thread est activé (voir plus bas).

Un thread ordonnancé selon SCHED_DEADLINE qui appelle sched_yield(2) cédera la priorité à
la sous-tâche en cours et attendra une nouvelle période pour débuter.

SCHED_OTHER : ordonnancement temps partagé par défaut
SCHED_OTHER peut être utilisé seulement pour la priorité statique 0 (c’est-à-dire que les
threads sous politique temps réel ont la priorité sur les processus SCHED_OTHER).
SCHED_OTHER est l’ordonnanceur temps partagé de Linux prévu pour tous les threads n’ayant
pas besoin des mécanismes temps réel spéciaux.

Le thread à exécuter est choisi dans la liste des threads de priorité statique 0, en
utilisant une priorité dynamique qui ne s'applique que dans cette liste. La priorité
dynamique est basée sur la valeur de politesse (« nice ») du thread (voir ci-dessous) et
est incrémentée à chaque quantum de temps où le thread est prêt, mais non sélectionné par
l'ordonnanceur. Cela garantit une progression équitable de tous les threads SCHED_OTHER.

Dans le code source du noyau Linux, la politique SCHED_OTHER est en fait appelée
SCHED_NORMAL.

La valeur de politesse
La valeur de politesse est un attribut pouvant être utilisé pour influencer l’ordonnanceur
en faveur ou défaveur d’un processus dans les choix d’ordonnancement. Elle affecte
l’ordonnancement des processus SCHED_OTHER et SCHED_BATCH (voir ci-dessous). La valeur de
politesse peut être modifiée avec nice(2), setpriority(2) ou sched_setattr(2).

Selon POSIX.1, la valeur de politesse est un attribut par processus, c’est-à-dire que les
threads dans un processus devraient partager la valeur de politesse. Cependant, dans
Linux, cette valeur est un attribut par thread : des threads distincts dans le même
processus peuvent avoir des valeurs de politesse différentes.

L’éventail des valeurs de politesse diffère selon les systèmes UNIX. Dans un Linux
moderne, il varie de −20 (priorité élevée) à +19 (priorité basse). Dans quelques autres
systèmes, la plage est de −20 à 20. Les tout premiers noyaux Linux (avant Linux 2.0)
avaient une plage de −infini à 15 .

De même, le degré auquel la valeur de politesse affecte l’ordonnancement respectif des
processus SCHED_OTHER varie selon les systèmes UNIX et selon les versions du noyau Linux.

Avec l’arrivée de l’ordonnanceur CFS dans le noyau 2.6.23, Linux a adopté un algorithme
qui provoque des différences relatives aux valeurs de politesse ayant un impact plus
important. Dans l’implémentation actuelle, chaque unité de différence dans les valeurs de
politesse dans deux processus aboutit à un facteur de 1,25 dans le degré dont
l’ordonnancement favorise le processus de plus haute priorité. Cela fait que les très
petites valeurs de priorité (+19) fournissent vraiment peu de CPU pour un processus à
chaque fois qu’il existe une charge de plus haute priorité sur le système, et cela fait
que les hautes valeurs (−20) fournissent la plus grande partie du CPU aux applications en
ayant besoin (par exemple, certaines applications audio).

Dans Linux, la limite de ressources RLIMIT_NICE peut être utilisée pour définir une limite
jusqu'à laquelle une valeur de politesse de processus non privilégié peut être élevée.
Consultez setrlimit(2) pour les détails.

Pour davantage d’explications à propos de la valeur de politesse, consultez ci-dessous les
sous-sections sur la fonctionnalité d’autogroupe et sur l’ordonnancement de groupe.

SCHED_BATCH : ordonnancement de processus 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 petite pénalité
d'ordonnancement vis-à-vis du comportement au réveil, ainsi le thread sera légèrement
désavantagé dans les décisions d'ordonnancement.

Cette politique est utile pour les charges de travail non interactives, mais qui ne
souhaitent pas diminuer leur valeur de politesse, ou pour celles qui veulent une politique
d'ordonnancement déterministe sans que l'interactivité ne cause de préemptions
supplémentaires (entre les tâches des charges).

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 politesse 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 politesse +19 avec les politiques SCHED_OTHER ou SCHED_BATCH).

Réinitialiser la politique d'ordonnancement pour les processus enfant
Chaque thread possède un attribut d'ordonnancement reset-on-fork. Lorsque cet attribut est
défini, les enfants créés au moyen de fork(2) n'héritent pas des politiques
d'ordonnancement nécessitant des droits. L'attribut reset-on-fork peut être défini soit :

– en appliquant un OU logique à l'attribut SCHED_RESET_ON_FORK dans l'argument policy au
moment de l'appel à sched_setscheduler(2) (à partir de Linux 2.6.32) ;

– ou en ajoutant l'argument SCHED_FLAG_RESET_ON_FORK dans attr.sched_flags au moment de
l'appel à sched_setattr(2).

Notez que les constantes utilisées dans ces deux API ont des noms différents. La
disposition de l'attribut reset-on-fork peut, de façon analogue, être obtenue au moyen de
sched_getscheduler(2) et de sched_getattr(2).

La fonctionnalité reset-on-fork 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 enfant.

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

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

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

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 cela ne pouvait être fait que si l'UID
effectif de l'appelant é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 était modifiée.

Un thread doit avoir des droits spécifiques (CAP_SYS_NICE) pour pouvoir affecter ou
modifier la politique SCHED_DEADLINE.

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 à sa 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 n'est 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 à la politique 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_OTHER 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.

Limiter l'utilisation CPU des processus temps-réel et à échéances.
Une boucle sans fin non bloquante dans un thread ordonnancé selon une politique
SCHED_FIFO, SCHED_RR ou SCHED_DEADLINE peut potentiellement bloquer indéfiniment l’accès
au CPU de tous les threads. Avant Linux 2.6.25, le seul moyen d'éviter qu'un processus
temps réel hors de contrôle ne bloque le système était d'exécuter (sur la console) un
shell ayant un priorité statique supérieure à celle de l'application testée. Cela
permettait d'exécuter en urgence une commande kill sur les applications temps réel en
cours de test qui ne se bloquaient pas ou ne se terminaient pas comme prévu.

Depuis Linux 2.6.25, il existe d'autres techniques pour traiter le cas des processus temps
réel et à échéances qui sont hors de contrôle. L'une de ces techniques consiste à utiliser
la limite de ressources RLIMIT_RTTIME pour définir la limite du temps CPU qu'un processus
temps réel a le droit de consommer. Consultez getrlimit(2) pour plus de détails.

Depuis la version 2.6.25, Linux propose également deux fichiers /proc qui peuvent être
utilisés pour réserver une certaine quantité de temps CPU aux processus non temps réel. La
réservation de temps CPU par ce moyen permet d'allouer du temps CPU, par exemple, à un
shell administrateur pour qu'il puisse exécuter une commande kill sur un processus hors de
contrôle. Ces deux fichiers définissent des valeurs exprimées en microseconde :

/proc/sys/kernel/sched_rt_period_us
Ce fichier définit une période d'ordonnancement correspondant à 100 % de la bande
passante du CPU. La valeur contenue dans ce fichier peut aller de 1 à INT_MAX, soit
une durée allant de 1 microseconde à environ 35 minutes. La valeur par défaut
contenue dans ce fichier est 1 000 000 (1 seconde).

/proc/sys/kernel/sched_rt_runtime_us
La valeur contenue dans ce fichier définit quelle part d'une « période » peut être
utilisée par des processus temps réel et à échéances. La valeur contenue dans ce
fichier peut aller de −1 à INT_MAX −1. −1 fixe un temps d'exécution égal à la
période, c'est à dire qu'aucun temps CPU n'est réservé pour les processus non temps
réel (ce qui correspond au comportement de Linux avant la version 2.6.25 du noyau).
La valeur par défaut contenue dans ce fichier est 950 000 (0,95 seconde), ce qui
signifie que 5 % du temps CPU est réservé aux processus qui ne s'exécutent pas
selon une politique d'ordonnancement temps réel ou à échéances.

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 enfant héritent de la politique d'ordonnancement et des paramètres associés
lors d'un fork(2). La politique 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 ; cela peut être effectué avec mlock(2) ou
mlockall(2).

Fonctionnalité d’autogroupage
Depuis Linux 2.6.38, le noyau fournit une fonctionnalité connue comme l’autogroupage pour
améliorer les performances des bureaux interactifs confrontés à des charges de travail
multiprocessus utilisant énormément le CPU telles que la construction du noyau Linux avec
un grand nombre de processus de construction en parallèle (c’est-à-dire l’indicateur -j de
make(1)).

Cette fonction opère en conjonction avec l’ordonnancement CFS et nécessite un noyau
configuré avec CONFIG_SCHED_AUTOGROUP. Sur un système en cours d’exécution, cette
fonctionnalité est activée ou désactivée à l’aide du fichier
/proc/sys/kernel/sched_autogroup_enabled. Une valeur 0 désactive cette fonctionnalité
tandis qu’une valeur 1 l’active. La valeur par défaut dans ce fichier est 1 à moins que le
noyau ait été amorcé avec le paramètre noautogroup.

Un nouvel autogroupe est créé quand une nouvelle session est créée à l’aide de setsid(2).
Cela se produit, par exemple, quand une nouvelle fenêtre de terminal est démarrée. Un
nouveau processus créé par fork(2) hérite de l’appartenance d’autogroupe de son parent.
Par conséquent, tous les processus dans une session sont membres du même autogroupe. Un
autogroupe est automatiquement détruit quand le dernier processus du groupe se termine.

Lorsque l’autogroupage est activé, tous les membres d’un autogroupe sont placés dans le
même ordonnanceur « groupe de tâches » du noyau. L’ordonnanceur CFS emploie un algorithme
qui égalise la distribution des cycles du CPU entre les groupes de tâches. Le bénéfice qui
en découle pour la performance de bureau interactif peut être décrit à l’aide de l’exemple
qui suit.

Supposons qu’il existe deux autogroupes en compétition pour le même CPU (c’est-à-dire soit
un système avec un seul CPU, soit l’utilisation de taskset(1) pour confiner tous les
processus sur le même CPU sur un système SMP). Le premier groupe contient dix processus
liés à un CPU d’une construction de noyau démarrée avec make -j10. L’autre groupe contient
un seul processus lié à un CPU : un lecteur vidéo. Le résultat de l’autogroupage est que
les deux groupes recevront chacun la moitié des cycles CPU. C’est-à-dire que le lecteur
vidéo recevra 50 % des cycles CPU, plutôt que seulement 9 % des cycles, ce qui conduirait
probablement à une lecture vidéo dégradée. La situation sur le système SMP est plus
complexe, mais l’effet général est le même : l’ordonnanceur répartit les cycles CPU dans
les groupes de tâches de telle façon qu’un autogroupe contenant un grand nombre de
processus liés à un CPU n’aboutisse pas à un accaparement des cycles CPU au détriment des
autres travaux dans le système.

L’appartenance à un autogroupe de processus (groupe de tâches) peut être vue dans le
fichier /proc/[pid]/autogroup:

$ cat /proc/1/autogroup
/autogroup-1 nice 0

Ce fichier peut aussi être utilisé pour modifier la bande passante de CPU allouée à un
autogroupe. Cela peut être réalisé en écrivant un nombre dans le champ « nice » du fichier
pour définir la valeur de politesse de l’autogroupe. L’intervalle autorisé va de +19
(priorité basse) à -20 (priorité haute). L’écriture d’une valeur en dehors de cet
intervalle provoquera l’échec de write(2) avec l’erreur EINVAL.

Le réglage de la politesse de l’autogroupe a la même acception que la valeur de politesse
du processus, mais s’applique à la répartition des cycles CPU à un autogroupe dans son
ensemble, basée sur les valeurs relatives de politesse des autres autogroupes. Pour un
processus dans un autogroupe, les cycles CPU qu’il reçoit sont déduits de la valeur de
politesse de l’autogroupe (comparée aux autres autogroupes) et de la valeur de politesse
du processus (comparée aux autres processus dans le même autogroupe).

L’utilisation du contrôleur de CPU cgroups(7) pour placer les processus dans des cgroups
autres que le cgroup racine du CPU contourne l’effet de l’autogroupage.

La fonctionnalité d’autogroupage groupe seulement les processus ordonnancés selon des
politiques non temps réel (SCHED_OTHER, SCHED_BATCH et SCHED_IDLE). Elle ne groupe pas les
processus ordonnancés selon les politiques temps réel et à échéances. Ceux-ci sont
ordonnancés selon les règles décrites ci-dessus.

Valeur de politesse et ordonnancement de groupe
Lors de l’ordonnancement de processus non temps réel (c’est-à-dire ceux ordonnancés selon
les politiques SCHED_OTHER, SCHED_BATCH et SCHED_IDLE), L’ordonnanceur CFS emploie une
technique connue comme « ordonnancement de groupe » (group scheduling) si le noyau a été
configuré avec l’option CONFIG_FAIR_GROUP_SCHED (ce qui est typique).

Avec l’ordonnancement de groupe, les threads sont ordonnancés dans des « groupes de
tâches ». Celles-ci ont une relation hiérarchique, avec comme racine le groupe de tâches
initial du système connu comme « groupe de tâches racine » (root task group). Les groupes
de tâches sont constitués dans les circonstances suivantes :

– Tous les threads dans un cgroup du CPU forment un groupe de tâches. Le parent de ce
groupe de tâches est le groupe de tâches du cgroup parent correspondant.

– Si l’autogroupage est activé, alors tous les threads qui sont (implicitement) placés
dans un autogroupe (c’est-à-dire la même session, telle que créée par setsid(2))
forment un groupe de tâches. Chaque nouvel autogroupe est par conséquent un groupe de
tâches distinct. Le groupe de tâches racine est le parent de tous les autogroupes de ce
type.

– Si l’autogroupage est activé, alors le groupe de tâches racine se compose de tous les
processus dans le cgroup racine du CPU qui n’étaient pas par ailleurs placés
implicitement dans un nouvel autogroupe.

– Si l’autogroupage est désactivé, alors le groupe de tâches racine est constitué de tous
les processus dans le cgroup racine du CPU.

– Si l’ordonnancement de groupe a été désactivé (c’est-à-dire que le noyau a été
configuré sans CONFIG_FAIR_GROUP_SCHED), alors tous les processus du système sont en
théorie placés dans un groupe de tâches unique.

Avec l’ordonnancement de groupe, une valeur de politesse de thread a un effet sur les
décisions d’ordonnancement seulement relatives aux autres threads dans le même groupe de
tâches. Cela a quelques conséquences surprenantes en terme de sémantique traditionnelle de
la valeur de politesse sur les systèmes UNIX. En particulier, si l’autogroupage est activé
(par défaut dans diverses distributions), alors l’emploi de setpriority(2) ou nice(1) sur
un processus a un effet seulement sur l’ordonnancement concernant les autres processus
exécutés dans la même session (classiquement : la même fenêtre de terminal).

Inversement, pour deux processus qui sont (par exemple) les seuls processus liés à un CPU
dans différentes sessions (par exemple, des fenêtres distinctes de terminal, chacune des
tâches étant liée à un autogroupe distinct), modifier la valeur de politesse du processus
d’une des sessions n’a pas d’effet en terme de décision d’ordonnancement relative au
processus dans l’autre session. Un contournement utile possible consiste à utiliser une
commande telle que la suivante pour modifier la valeur de politesse de l’autogroupe pour
tous les processus dans une session de terminal :

$ echo 10 > /proc/self/autogroup

Fonctionnalités temps réel dans le noyau Linux principal
Depuis le noyau 2.6.18, Linux a été graduellement pourvu de capacités temps réel, la
plupart étant dérivées de l’ancien ensemble de greffons realtime-preempt. Jusqu'à ce que
ces greffons aient été entièrement fusionnés dans le noyau principal, ils devront être
installés pour atteindre les meilleures performances temps réel. Ces greffons
s'appellent :

patch-version-noyau-rtversion-greffon

et peuvent être téléchargés à partir de ⟨http://www.kernel.org/pub/linux/kernel/projects
/rt/⟩.

Sans les greffons 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 fournissent respectivement
« aucune », « quelque » et une « considérable » réduction de la pire latence
d'ordonnancement.

Avec les greffons 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 sont alors utilisées pour lancer un thread avec une vraie
priorité temps réel et une latence minimale d'ordonnancement de pire cas.

NOTES

       Le contrôleur cgroups(7) de CPU peut être utilisé pour limiter la consommation de CPU  par
       les groupes de processus.

       À  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  souples  (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  par  le
       noyau  et  que l'ordonnanceur O(1), nouvellement introduit, assure que le temps nécessaire
       pour planifier soit fixé 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.

VOIR AUSSI

       chcpu(1), chrt(1), lscpu(1), ps(1), taskset(1), top(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_getscheduler(2),
       sched_rr_get_interval(2), sched_setaffinity(2), sched_setparam(2), sched_setscheduler(2),
       sched_yield(2), setpriority(2), pthread_getaffinity_np(3), pthread_getschedparam(3),
       pthread_setaffinity_np(3), sched_getcpu(3), capabilities(7), cpuset(7)

       Programming for the real world – POSIX.4 de Bill O. Gallmeister,  O'Reilly  &  Associates,
       Inc., ISBN 1-56592-074-0.

       Les   fichiers   source   du   noyau   Linux   Documentation/scheduler/sched-deadline.txt,
       Documentation/scheduler/sched-rt-group.txt,   Documentation/scheduler/sched-design-CFS.txt
       et Documentation/scheduler/sched-nice-design.txt

COLOPHON

       Cette  page  fait partie de la publication 5.10 du projet man-pages Linux. Une description
       du projet et des instructions pour signaler des anomalies et la dernière version de  cette
       page peuvent être trouvées à l'adresse https://www.kernel.org/doc/man-pages/.

TRADUCTION

       La  traduction  française  de  cette  page  de  manuel  a  été créée par Christophe Blaess
       <https://www.blaess.fr/christophe/>, Stéphan  Rafin  <stephan.rafin@laposte.net>,  Thierry
       Vignaud  <tvignaud@mandriva.com>,  François Micaux, Alain Portal <aportal@univ-montp2.fr>,
       Jean-Philippe   Guérard   <fevrier@tigreraye.org>,   Jean-Luc   Coulon   (f5ibh)    <jean-
       luc.coulon@wanadoo.fr>,    Julien    Cristau    <jcristau@debian.org>,    Thomas   Huriaux
       <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
       Duneau  <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis
       Barbier  <barbier@debian.org>,  David  Prévot   <david@tilapin.org>,   Cédric   Boutillier
       <cedric.boutillier@gmail.com>,   Frédéric   Hantrais  <fhantrais@gmail.com>  et  Jean-Paul
       Guillonneau <guillonneau.jeanpaul@free.fr>

       Cette traduction est une documentation libre ; veuillez vous reporter  à  la  GNU  General
       Public   License   version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩  concernant  les
       conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
       message à debian-l10n-french@lists.debian.org ⟨⟩.