.\" -*- coding: UTF-8 -*- .\" Copyright (C) 2014 Michael Kerrisk .\" and Copyright (C) 2014 Peter Zijlstra .\" and Copyright (C) 2014 Juri Lelli .\" Various pieces from the old sched_setscheduler(2) page .\" Copyright (C) Tom Bjorkholm, Markus Kuhn & David A. Wheeler 1996-1999 .\" and Copyright (C) 2007 Carsten Emde .\" and Copyright (C) 2008 Michael Kerrisk .\" .\" SPDX-License-Identifier: GPL-2.0-or-later .\" .\" Worth looking at: http://rt.wiki.kernel.org/index.php .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH sched 7 "2 mai 2024" "Pages du manuel de Linux 6.9.1" .SH NOM sched \- Aperçu de l’ordonnancement de CPU .SH 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) ». .SS "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). .TP \fBnice\fP(2) Définir une nouvelle valeur de politesse pour le thread appelant et renvoyer cette nouvelle valeur. .TP \fBgetpriority\fP(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. .TP \fBsetpriority\fP(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. .TP \fBsched_setscheduler\fP(2) Définir la politique d'ordonnancement et les paramètres du thread indiqué. .TP \fBsched_getscheduler\fP(2) Renvoyer la politique d'ordonnancement du thread indiqué. .TP \fBsched_setparam\fP(2) Définir les paramètres d'ordonnancement du thread indiqué. .TP \fBsched_getparam\fP(2) Récupérer les paramètres d'ordonnancement du thread indiqué. .TP \fBsched_get_priority_max\fP(2) Renvoyer la priorité la plus haute disponible pour la politique d'ordonnancement indiquée. .TP \fBsched_get_priority_min\fP(2) Renvoyer la priorité la plus basse disponible pour la politique d'ordonnancement indiquée. .TP \fBsched_rr_get_interval\fP(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). .TP \fBsched_yield\fP(2) Provoquer la libération du CPU par l'appelant afin de permettre l’exécution d'autres threads. .TP \fBsched_setaffinity\fP(2) Définir le masque d'affinité CPU du thread indiqué (propre à Linux). .TP \fBsched_getaffinity\fP(2) Récupérer le masque d'affinité CPU du thread indiqué (propre à Linux). .TP \fBsched_setattr\fP(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 \fBsched_setscheduler\fP(2) et de \fBsched_setparam\fP(2). .TP \fBsched_getattr\fP(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 \fBsched_getscheduler\fP(2) et de \fBsched_getparam\fP(2). .SS "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 \fIstatique\fP, \fIsched_priority\fP. 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. .P Pour les threads ordonnancés sous l'une des politiques d'ordonnancement normales (\fBSCHED_OTHER\fP, \fBSCHED_IDLE\fP, \fBSCHED_BATCH\fP), \fIsched_priority\fP n'est pas utilisée dans les décisions d'ordonnancement (et doit valoir 0). .P Les processus ordonnancés sous l'une des politiques d'ordonnancement temps réel (\fBSCHED_FIFO\fP, \fBSCHED_RR\fP) ont une valeur \fIsched_priority\fP 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 \fBsched_get_priority_min\fP(2) et \fBsched_get_priority_max\fP(2) pour connaître l'intervalle des priorités gérées pour une politique particulière. .P Théoriquement, l'ordonnanceur entretient une liste de tous les threads prêts pour l’exécution pour chaque valeur possible de \fIsched_priority\fP. 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. .P 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. .P 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. .SS "SCHED_FIFO\ : Ordonnancement premier entré, premier sorti" \fBSCHED_FIFO\fP ne peut être utilisée qu'avec des priorités statiques supérieures à 0, ce qui signifie que dès qu'un thread \fBSCHED_FIFO\fP devient prêt, il préempte n’importe quel thread \fBSCHED_OTHER\fP, \fBSCHED_BATCH\fP ou \fBSCHED_IDLE\fP en cours d'exécution. \fBSCHED_FIFO\fP est un ordonnancement simple sans découpage temporel. Pour les threads ordonnancés selon la politique \fBSCHED_FIFO\fP, les règles suivantes sont appliquées : .IP \- 3 Un thread \fBSCHED_FIFO\fP 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. .IP \- Quand un thread \fBSCHED_FIFO\fP bloqué devient prêt, il est inséré en fin de liste pour sa priorité. .IP \- Si un appel à \fBsched_setscheduler\fP(2), \fBsched_setparam\fP(2), \fBsched_setattr\fP(2), \fBpthread_setschedparam\fP(3) ou \fBpthread_setschedprio\fP(3) modifie la priorité du thread \fBSCHED_FIFO\fP prêt ou en cours d’exécution, identifié par \fIpid\fP, l’effet sur la position du thread dans la liste dépend de la direction de la modification de la priorité des threads : .RS .IP (a) 5 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é. .IP (b) Si la priorité du thread est inchangée, sa position dans la liste des exécutions est inchangée. .IP (c) Si la priorité du thread est abaissée, il est placé en tête de liste pour sa nouvelle priorité. .RE .IP .\" In Linux 2.2.x and Linux 2.4.x, the thread is placed at the front of the queue .\" In Linux 2.0.x, the Right Thing happened: the thread went to the back -- MTK Selon POSIX.1\-2008, les modifications de priorité (ou politique) de thread en utilisant tout autre mécanisme que \fBpthread_setschedprio\fP(3) devraient aboutir à ce que le thread soit placé en fin de liste pour sa priorité. .IP \- Un thread appelant \fBsched_yield\fP(2) sera placé en fin liste. .P Aucun autre événement ne déplacera un thread ordonnancé selon la politique \fBSCHED_FIFO\fP dans la liste d’attente des threads prêts de priorité statique équivalente. .P Un thread \fBSCHED_FIFO\fP 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 \fBsched_yield\fP(2). .SS "SCHED_RR\ : ordonnancement tourniquet" .\" On Linux 2.4, the length of the RR interval is influenced .\" by the process nice value -- MTK .\" \fBSCHED_RR\fP est une amélioration simple de \fBSCHED_FIFO\fP. Tout ce qui est décrit pour \fBSCHED_FIFO\fP s'applique aussi à \fBSCHED_RR\fP, sauf que chaque thread ne dispose que d'un quantum de temps maximal pour son exécution. Si l’exécution d’un thread \fBSCHED_RR\fP 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 \fBSCHED_RR\fP 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 \fBsched_rr_get_interval\fP(2). .SS "SCHED_DEADLINE: ordonnancement sur échéances selon le modèle des tâches sporadiques." Depuis Linux 3.14, Linux offre une politique d'ordonnancement sur échéances (\fBSCHED_DEADLINE\fP). 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 \fBsched_setattr\fP(2) et \fBsched_getattr\fP(2) doivent être utilisés. .P 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 \fIéchéance relative\fP, avant laquelle elle doit achever son exécution, et un \fItemps d'exécution\fP 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é \fItemps d'activation\fP (également désigné temps d'appel (« request time ») ou temps de libération (« release time »)). Le \fItemps de lancement\fP est le moment auquel la tâche commence son exécution. L'\fIéchéance impérative\fP est obtenue en additionnant l'échéance relative et le temps d'activation. .P Le schéma suivant illustre ces termes : .P .in +4n .EX activation/réveil échéance impérative | temps du lancement | | | | v v v \-\-\-\-\-x\-\-\-\-\-\-\-\-xoooooooooooooooooooooooo\-\-\-\-\-\-\-\-x\-\-\-\-\-\-\-\-x\-\-\- |<\- temps d'exécution \->| |<\-\-\-\-\-\-\-\-\-\- échéance relative \-\-\-\-\-\-\-\-\-\->| |<\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- période \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\->| .EE .in .P Lorsqu'une politique \fBSCHED_DEADLINE\fP est activée au moyen de \fBsched_setattr\fP(2), il est possible de préciser trois paramètres : \fIRuntime\fP, \fIDeadline\fP et \fIPeriod\fP. 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 \fBSCHED_DEADLINE\fP, on obtient. .P .in +4n .EX activation/réveil échéance impérative | temps du lancement | | | | v v v \-\-\-\-\-x\-\-\-\-\-\-\-\-xoooooooooooooooooooooooo\-\-\-\-\-\-\-\-x\-\-\-\-\-\-\-\-x\-\-\- |<\-\-\-\-\-\-\- Exécution \-\-\-\-\-\-\->| |<\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- Échéance \-\-\-\-\-\-\-\-\-\-\-\->| |<\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- Période \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\->| .EE .in .P .\" FIXME It looks as though specifying sched_period as 0 means .\" "make sched_period the same as sched_deadline". .\" This needs to be documented. Les trois paramètres de configuration de l'ordonnancement sur échéances correspondent aux champs \fIsched_runtime\fP, \fIsched_deadline\fP et \fIsched_period\fP de la structure \fIsched_attr\fP (consultez \fBsched_setattr\fP(2)). Ces champs sont exprimés en nanosecondes. Si la valeur 0 est affectée à \fIsched_period\fP, ce paramètre prend la valeur de \fIsched_deadline\fP. .P Le noyau exige que : .P .in +4n .EX sched_runtime <= sched_deadline <= sched_period .EE .in .P .\" See __checkparam_dl in kernel/sched/core.c 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\[ha]63. Si la valeur de l'un de ces paramètres sort de cet intervalle, \fBsched_setattr\fP(2) échoue en renvoyant l'erreur \fBEINVAL\fP. .P 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). .P 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 \fBSCHED_DEADLINE\fP 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 \fBSCHED_DEADLINE\fP 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, \fBsched_setattr\fP(2) échoue et renvoie l'erreur \fBEBUSY\fP. .P 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 \fIRuntime\fP par \fIPeriod\fP, l'utilisation pour ce thread vaut son \fIRuntime\fP divisé par sa \fIPeriod\fP. .P Pour assurer les conditions qui sont requises lorsqu'un thread est autorisé à utiliser la politique \fBSCHED_DEADLINE\fP, les threads \fBSCHED_DEADLINE\fP ont la priorité la plus élevée parmi tous les threads (contrôlable par l'utilisateur) du système. Si un thread ordonnancé selon \fBSCHED_DEADLINE\fP est prêt, il aura la priorité sur tout autre thread ordonnancé par une autre politique. .P Un appel à \fBfork\fP(2) effectué par un thread ordonnancé selon la politique \fBSCHED_DEADLINE\fP échouera en renvoyant l'erreur \fBEAGAIN\fP, sauf dans le cas ou l'attribut « reset\-on\-fork » du thread est activé (voir plus bas). .P .\" .\" FIXME Calling sched_getparam() on a SCHED_DEADLINE thread .\" fails with EINVAL, but sched_getscheduler() succeeds. .\" Is that intended? (Why?) .\" Un thread ordonnancé selon \fBSCHED_DEADLINE\fP qui appelle \fBsched_yield\fP(2) cédera la priorité à la sous\-tâche en cours et attendra une nouvelle période pour débuter. .SS "SCHED_OTHER\ : ordonnancement temps partagé par défaut" \fBSCHED_OTHER\fP 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 \fBSCHED_OTHER\fP). \fBSCHED_OTHER\fP 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. .P Le thread à exécuter est choisi dans la liste des threads de priorité statique 0, en utilisant une priorité \fIdynamique\fP 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 \fBSCHED_OTHER\fP. .P .\" Dans le code source du noyau Linux, la politique \fBSCHED_OTHER\fP est en fait appelée \fBSCHED_NORMAL\fP. .SS "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 \fBSCHED_OTHER\fP et \fBSCHED_BATCH\fP (voir ci\-dessous). La valeur de politesse peut être modifiée avec \fBnice\fP(2), \fBsetpriority\fP(2) ou \fBsched_setattr\fP(2). .P 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. .P .\" Linux before 1.3.36 had \-infinity..15. .\" Since Linux 1.3.43, Linux has the range \-20..19. 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 . .P De même, le degré auquel la valeur de politesse affecte l’ordonnancement respectif des processus \fBSCHED_OTHER\fP varie selon les systèmes UNIX et selon les versions du noyau Linux. .P Avec l’arrivée de l’ordonnanceur CFS dans Linux 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). .P Dans Linux, la limite de ressources \fBRLIMIT_NICE\fP 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 \fBsetrlimit\fP(2) pour les détails. .P .\" 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. .SS "SCHED_BATCH\ : ordonnancement de processus par lots" (Depuis Linux 2.6.16) \fBSCHED_BATCH\fP ne peut être utilisée qu'avec une priorité statique de 0. Cette politique est similaire à \fBSCHED_OTHER\fP 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. .P .\" The following paragraph is drawn largely from the text that .\" accompanied Ingo Molnar's patch for the implementation of .\" SCHED_BATCH. .\" commit b0a9499c3dd50d333e2aedb7e894873c58da3785 .\" 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). .SS "SCHED_IDLE : ordonnancement de tâches de très faible priorité" (Depuis Linux 2.6.23.) \fBSCHED_IDLE\fP ne peut être utilisée qu'avec une priorité statique de 0 ; la valeur de politesse n'a pas d'influence pour cette politique. .P .\" 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 \fBSCHED_OTHER\fP ou \fBSCHED_BATCH\fP). .SS "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 \fBfork\fP(2) n'héritent pas des politiques d'ordonnancement nécessitant des droits. L'attribut reset\-on\-fork peut être défini soit : .IP \- 3 en appliquant un OU logique à l'attribut \fBSCHED_RESET_ON_FORK\fP dans l'argument \fIpolicy\fP au moment de l'appel à \fBsched_setscheduler\fP(2) (à partir de Linux 2.6.32) ; .IP \- ou en ajoutant l'argument \fBSCHED_FLAG_RESET_ON_FORK\fP dans \fIattr.sched_flags\fP au moment de l'appel à \fBsched_setattr\fP(2). .P 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 \fBsched_getscheduler\fP(2) et de \fBsched_getattr\fP(2). .P 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 \fBRLIMIT_RTTIME\fP (consultez \fBgetrlimit\fP(2)) en créant de nombreux processus enfant. .P 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 : .IP \- 3 Si le thread appelant a une politique d'ordonnancement \fBSCHED_FIFO\fP ou \fBSCHED_RR\fP, la politique pour les processus enfant est réinitialisée à \fBSCHED_OTHER\fP. .IP \- Si le processus appelant a une valeur de politesse négative, elle est mise à zéro pour les processus enfant. .P .\" Une fois que l'attribut reset\-on\-fork est activé, il ne peut être désactivé que si le thread possède la capacité \fBCAP_SYS_NICE\fP. Cet attribut est désactivé pour les processus enfant créés avec \fBfork\fP(2). .SS "Privilèges et limites de ressources" Avant Linux 2.6.12, seuls les threads privilégiés (\fBCAP_SYS_NICE\fP) 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 \fBSCHED_OTHER\fP 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 \fIpid\fP) dont la politique était modifiée. .P Un thread doit avoir des droits spécifiques (\fBCAP_SYS_NICE\fP) pour pouvoir affecter ou modifier la politique \fBSCHED_DEADLINE\fP. .P Depuis Linux 2.6.12, la limite de ressources \fBRLIMIT_RTPRIO\fP définit un plafond pour la priorité statique d'un thread non privilégié pour les politiques \fBSCHED_RR\fP et \fBSCHED_FIFO\fP. Les règles pour modifier la politique d'ordonnancement et la priorité sont les suivantes : .IP \- 3 Si un thread non privilégié a une limite souple \fBRLIMIT_RTPRIO\fP 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 \fBRLIMIT_RTPRIO\fP. .IP \- Si la limite souple \fBRLIMIT_RTPRIO\fP 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. .IP \- 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. .IP \- .\" commit c02aa73b1d18e43cfd79c2f193b225e84ca497c8 Des règles particulières s'appliquent à la politique \fBSCHED_IDLE\fP. Avant Linux 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 \fBRLIMIT_RTPRIO\fP. Depuis Linux 2.6.39, un thread non privilégié peut basculer vers la politique \fBSCHED_BATCH\fP ou \fBSCHED_OTHER\fP tant que sa valeur de politesse tombe dans l'intervalle permis par sa limite de ressources \fBRLIMIT_NICE\fP (consultez \fBgetrlimit\fP(2)). .P Les threads privilégiés (\fBCAP_SYS_NICE\fP) ignorent la limite \fBRLIMIT_RTPRIO\fP : comme avec d'anciens noyaux, ils peuvent modifier arbitrairement la politique d'ordonnancement et la priorité. Consultez \fBgetrlimit\fP(2) pour plus d'informations sur \fBRLIMIT_RTPRIO\fP. .SS "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 \fBSCHED_FIFO\fP, \fBSCHED_RR\fP ou \fBSCHED_DEADLINE\fP 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. .P 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 \fBRLIMIT_RTTIME\fP pour définir la limite du temps CPU qu'un processus temps réel a le droit de consommer. Consultez \fBgetrlimit\fP(2) pour plus de détails. .P Depuis, Linux 2.6.25 propose également deux fichiers \fI/proc\fP 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 : .TP \fI/proc/sys/kernel/sched_rt_period_us\fP 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 à \fBINT_MAX\fP, 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). .TP \fI/proc/sys/kernel/sched_rt_runtime_us\fP 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 à \fBINT_MAX\fP −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 avant Linux 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. .SS "Temps de réponse" .\" as described in .\" .BR request_irq (9). 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 ». .SS Divers Les processus enfant héritent de la politique d'ordonnancement et des paramètres associés lors d'un \fBfork\fP(2). La politique et les paramètres d'ordonnancement sont conservés au travers d'un \fBexecve\fP(2). .P .\" 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 \fBmlock\fP(2) ou \fBmlockall\fP(2). .SS "Fonctionnalité d’autogroupage" .\" commit 5091faa449ee0b7d73bc296a93bca9540fc51d0a 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 \fB\-j\fP de \fBmake\fP(1)). .P Cette fonction opère en conjonction avec l’ordonnancement CFS et nécessite un noyau configuré avec \fBCONFIG_SCHED_AUTOGROUP\fP. Sur un système en cours d’exécution, cette fonctionnalité est activée ou désactivée à l’aide du fichier \fI/proc/sys/kernel/sched_autogroup_enabled\fP. 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 \fInoautogroup\fP. .P Un nouvel autogroupe est créé quand une nouvelle session est créée à l’aide de \fBsetsid\fP(2). Cela se produit, par exemple, quand une nouvelle fenêtre de terminal est démarrée. Un nouveau processus créé par \fBfork\fP(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. .P 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. .P .\" Mike Galbraith, 25 Nov 2016: .\" I'd say something more wishy-washy here, like cycles are .\" distributed fairly across groups and leave it at that, as your .\" detailed example is incorrect due to SMP fairness (which I don't .\" like much because [very unlikely] worst case scenario .\" renders a box sized group incapable of utilizing more that .\" a single CPU total). For example, if a group of NR_CPUS .\" size competes with a singleton, load balancing will try to give .\" the singleton a full CPU of its very own. If groups intersect for .\" whatever reason on say my quad lappy, distribution is 80/20 in .\" favor of the singleton. 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 \fBtaskset\fP(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 \fImake\ \-j10\fP. 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. .P L’appartenance à un autogroupe de processus (groupe de tâches) peut être vue dans le fichier \fI/proc/\fPpid\fI/autogroup\fP : .P .in +4n .EX $ \fBcat /proc/1/autogroup\fP /autogroup\-1 nice 0 .EE .in .P .\" FIXME . .\" Because of a bug introduced in Linux 4.7 .\" (commit 2159197d66770ec01f75c93fb11dc66df81fd45b made changes .\" that exposed the fact that autogroup didn't call scale_load()), .\" it happened that *all* values in this range caused a task group .\" to be further disfavored by the scheduler, with \-20 resulting .\" in the scheduler mildly disfavoring the task group and +19 greatly .\" disfavoring it. .\" .\" A patch was posted on 23 Nov 2016 .\" ("sched/autogroup: Fix 64bit kernel nice adjustment"; .\" check later to see in which kernel version it lands. 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 \fBwrite\fP(2) avec l’erreur \fBEINVAL\fP. .P 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). .P L’utilisation du contrôleur de CPU \fBcgroups\fP(7) pour placer les processus dans des cgroups autres que le cgroup racine du CPU contourne l’effet de l’autogroupage. .P .\" La fonctionnalité d’autogroupage groupe seulement les processus ordonnancés selon des politiques non temps réel (\fBSCHED_OTHER\fP, \fBSCHED_BATCH\fP et \fBSCHED_IDLE\fP). 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. .SS "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 \fBSCHED_OTHER\fP, \fBSCHED_BATCH\fP et \fBSCHED_IDLE\fP), L’ordonnanceur CFS emploie une technique connue comme « ordonnancement de groupe » (group scheduling) si le noyau a été configuré avec l’option \fBCONFIG_FAIR_GROUP_SCHED\fP (ce qui est typique). .P 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 : .IP \- 3 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. .IP \- 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 \fBsetsid\fP(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. .IP \- 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. .IP \- 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. .IP \- Si l’ordonnancement de groupe a été désactivé (c’est\-à\-dire que le noyau a été configuré sans \fBCONFIG_FAIR_GROUP_SCHED\fP), alors tous les processus du système sont en théorie placés dans un groupe de tâches unique. .P Avec l’ordonnancement de groupe, une valeur de politesse de thread a un effet sur les décisions d’ordonnancement \fIseulement relatives aux autres threads dans le même groupe de tâches\fP. 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 \fBsetpriority\fP(2) ou \fBnice\fP(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). .P .\" More succinctly: the nice(1) command is in many cases a no-op since .\" Linux 2.6.38. .\" 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), \fImodifier la valeur de politesse du processus d’une des sessions\fP \fIn’a pas d’effet\fP 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 \fItous\fP les processus dans une session de terminal : .P .in +4n .EX $ \fBecho 10 > /proc/self/autogroup\fP .EE .in .SS "Fonctionnalités temps réel dans le noyau Linux principal" .\" FIXME . Probably this text will need some minor tweaking .\" ask Carsten Emde about this. Depuis Linux 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 \fIrealtime\-preempt\fP. 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 : .P .in +4n .EX patch\-\fIversion\-noyau\fP\-rt\fIversion\-greffon\fP .EE .in .P et peuvent être téléchargés à partir de .UR http://www.kernel.org\:/pub\:/linux\:/kernel\:/projects\:/rt/ .UE . .P 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 \fBCONFIG_PREEMPT_NONE\fP, \fBCONFIG_PREEMPT_VOLUNTARY\fP et \fBCONFIG_PREEMPT_DESKTOP\fP qui fournissent respectivement « aucune », « quelque » et une « considérable » réduction de la pire latence d'ordonnancement. .P Avec les greffons appliqués ou après leur pleine inclusion dans le noyau principal, la configuration supplémentaire \fBCONFIG_PREEMPT_RT\fP 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. .SH NOTES Le contrôleur \fBcgroups\fP(7) de CPU peut être utilisé pour limiter la consommation de CPU par les groupes de processus. .P À 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 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 Linux 2.6.17. .SH "VOIR AUSSI" .ad l .nh \fBchcpu\fP(1), \fBchrt\fP(1), \fBlscpu\fP(1), \fBps\fP(1), \fBtaskset\fP(1), \fBtop\fP(1), \fBgetpriority\fP(2), \fBmlock\fP(2), \fBmlockall\fP(2), \fBmunlock\fP(2), \fBmunlockall\fP(2), \fBnice\fP(2), \fBsched_get_priority_max\fP(2), \fBsched_get_priority_min\fP(2), \fBsched_getaffinity\fP(2), \fBsched_getparam\fP(2), \fBsched_getscheduler\fP(2), \fBsched_rr_get_interval\fP(2), \fBsched_setaffinity\fP(2), \fBsched_setparam\fP(2), \fBsched_setscheduler\fP(2), \fBsched_yield\fP(2), \fBsetpriority\fP(2), \fBpthread_getaffinity_np\fP(3), \fBpthread_getschedparam\fP(3), \fBpthread_setaffinity_np\fP(3), \fBsched_getcpu\fP(3), \fBcapabilities\fP(7), \fBcpuset\fP(7) .ad .P \fIProgramming for the real world – POSIX.4\fP de Bill O.\& Gallmeister, O'Reilly & Associates, Inc., ISBN 1\-56592\-074\-0. .P Les fichiers source du noyau Linux \fI\%Documentation/\:scheduler/\:sched\-deadline\:.txt\fP, \fI\%Documentation/\:scheduler/\:sched\-rt\-group\:.txt\fP, \fI\%Documentation/\:scheduler/\:sched\-design\-CFS\:.txt\fP et \fI\%Documentation/\:scheduler/\:sched\-nice\-design\:.txt\fP .PP .SH TRADUCTION La traduction française de cette page de manuel a été créée par Christophe Blaess , Stéphan Rafin , Thierry Vignaud , François Micaux, Alain Portal , Jean-Philippe Guérard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas François , Florentin Duneau , Simon Paillard , Denis Barbier , David Prévot , Cédric Boutillier , Frédéric Hantrais et Jean-Paul Guillonneau . .PP Cette traduction est une documentation libre ; veuillez vous reporter à la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 .UE concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. .PP Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à .MT debian-l10n-french@lists.debian.org .ME .