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 :

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

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

- 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 :

(a) 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é.

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

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é.

- 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.
Since Linux 3.14, Linux provides a deadline scheduling policy (SCHED_DEADLINE). This policy is currently
implemented using GEDF (Global Earliest Deadline First) in conjunction with CBS (Constant Bandwidth
Server). To set and fetch this policy and associated attributes, one must use the Linux-specific
sched_setattr(2) and sched_getattr(2) system calls.

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

In addition, under the current implementation, all of the parameter values must be at least 1024 (i.e.,
just over one microsecond, which is the resolution of the implementation), and less than 2^63. If any of
these checks fails, sched_setattr(2) fails with the error 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.

The range of the nice value varies across UNIX systems. On modern Linux, the range is -20 (high priority)
to +19 (low priority). On some other systems, the range is -20..20. Very early Linux kernels (before
Linux 2.0) had the range -infinity..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.

With the advent of the CFS scheduler in Linux 2.6.23, Linux adopted an algorithm that causes relative
differences in nice values to have a much stronger effect. In the current implementation, each unit of
difference in the nice values of two processes results in a factor of 1.25 in the degree to which the
scheduler favors the higher priority process. This causes very low nice values (+19) to truly provide
little CPU to a process whenever there is any other higher priority load on the system, and makes high
nice values (-20) deliver most of the CPU to applications that require it (e.g., some audio
applications).

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
Before Linux 2.6.12, only privileged (CAP_SYS_NICE) threads can set a nonzero static priority (i.e., set
a real-time scheduling policy). The only change that an unprivileged thread can make is to set the
SCHED_OTHER policy, and this can be done only if the effective user ID of the caller matches the real or
effective user ID of the target thread (i.e., the thread specified by pid) whose policy is being
changed.

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.

- Special rules apply for the SCHED_IDLE policy. Before Linux 2.6.39, an unprivileged thread operating
under this policy cannot change its policy, regardless of the value of its RLIMIT_RTPRIO resource
limit. Since Linux 2.6.39, an unprivileged thread can switch to either the SCHED_BATCH or the
SCHED_OTHER policy so long as its nice value falls within the range permitted by its RLIMIT_NICE
resource limit (see 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.
A nonblocking infinite loop in a thread scheduled under the SCHED_FIFO, SCHED_RR, or SCHED_DEADLINE
policy can potentially block all other threads from accessing the CPU forever. Before Linux 2.6.25, the
only way of preventing a runaway real-time process from freezing the system was to run (at the console)
a shell scheduled under a higher static priority than the tested application. This allows an emergency
kill of tested real-time applications that do not block or terminate as expected.

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.

Since Linux 2.6.25, Linux also provides two /proc files that can be used to reserve a certain amount of
CPU time to be used by non-real-time processes. Reserving CPU time in this fashion allows some CPU time
to be allocated to (say) a root shell that can be used to kill a runaway process. Both of these files
specify time values in microseconds:

/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
The value in this file specifies how much of the "period" time can be used by all real-time and
deadline scheduled processes on the system. The value in this file can range from -1 to INT_MAX-1.
Specifying -1 makes the run time the same as the period; that is, no CPU time is set aside for
non-real-time processes (which was the behavior before Linux 2.6.25). The default value in this
file is 950,000 (0.95 seconds), meaning that 5% of the CPU time is reserved for processes that
don't run under a real-time or deadline scheduling policy.

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.

Suppose that there are two autogroups competing for the same CPU (i.e., presume either a single CPU
system or the use of taskset(1) to confine all the processes to the same CPU on an SMP system). The
first group contains ten CPU-bound processes from a kernel build started with make -j10. The other
contains a single CPU-bound process: a video player. The effect of autogrouping is that the two groups
will each receive half of the CPU cycles. That is, the video player will receive 50% of the CPU cycles,
rather than just 9% of the cycles, which would likely lead to degraded video playback. The situation on
an SMP system is more complex, but the general effect is the same: the scheduler distributes CPU cycles
across task groups such that an autogroup that contains a large number of CPU-bound processes does not
end up hogging CPU cycles at the expense of the other jobs on the system.

A process's autogroup (task group) membership can be viewed via the file /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
Since Linux 2.6.18, Linux is gradually becoming equipped with real-time capabilities, most of which are
derived from the former realtime-preempt patch set. Until the patches have been completely merged into
the mainline kernel, they must be installed to achieve the best real-time performance. These patches are
named:

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.

       Originally, Standard Linux was intended as a  general-purpose  operating  system  being  able  to  handle
       background  processes,  interactive applications, and less demanding real-time applications (applications
       that need to usually meet timing deadlines). Although the Linux 2.6 allowed for kernel preemption and the
       newly  introduced  O(1)  scheduler  ensures  that  the time needed to schedule is fixed and deterministic
       irrespective of the number of active tasks, true real-time computing was not possible up to Linux 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.

       The  Linux  kernel  source  files  Documentation/scheduler/sched-deadline.txt,   Documentation/scheduler/
       sched-rt-group.txt,     Documentation/scheduler/sched-design-CFS.txt,     and    Documentation/scheduler/
       sched-nice-design.txt

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⟩.