sched(7) Miscellaneous Information Manual sched(7)
NOM
sched - Apercu de l'ordonnancement de CPU
DESCRIPTION
Depuis Linux 2.6.23, l'ordonnanceur par defaut est CFS (Completely Fair
Scheduler - ordonnanceur completement equitable). Il remplace
l'ordonnanceur precedent, << O(1) >>.
Resume des API
Linux fournit les appels systeme suivants pour controler le
comportement de l'ordonnancement du CPU, la politique et la priorite
des processus (ou, plus precisement, des threads).
nice(2)
Definir 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 possedes par un
utilisateur particulier.
setpriority(2)
Definir la valeur de politesse d'un thread, d'un groupe de
processus ou de l'ensemble des threads possedes par un
utilisateur particulier.
sched_setscheduler(2)
Definir la politique d'ordonnancement et les parametres du
thread indique.
sched_getscheduler(2)
Renvoyer la politique d'ordonnancement du thread indique.
sched_setparam(2)
Definir les parametres d'ordonnancement du thread indique.
sched_getparam(2)
Recuperer les parametres d'ordonnancement du thread indique.
sched_get_priority_max(2)
Renvoyer la priorite la plus haute disponible pour la politique
d'ordonnancement indiquee.
sched_get_priority_min(2)
Renvoyer la priorite la plus basse disponible pour la politique
d'ordonnancement indiquee.
sched_rr_get_interval(2)
Recuperer le quantum de temps alloue utilise pour les threads
ordonnances par une politique de type repartition par tourniquet
(round robin).
sched_yield(2)
Provoquer la liberation du CPU par l'appelant afin de permettre
l'execution d'autres threads.
sched_setaffinity(2)
Definir le masque d'affinite CPU du thread indique (propre a
Linux).
sched_getaffinity(2)
Recuperer le masque d'affinite CPU du thread indique (propre a
Linux).
sched_setattr(2)
Definir la politique d'ordonnancement et les parametres du
thread indique. Cet appel systeme (propre a Linux) fournit un
sur-ensemble de la fonctionnalite de sched_setscheduler(2) et de
sched_setparam(2).
sched_getattr(2)
Recuperer la politique d'ordonnancement et les parametres du
thread indique. Cet appel systeme (propre a Linux) fournit un
sur-ensemble de la fonctionnalite de sched_getscheduler(2) et de
sched_getparam(2).
Politiques d'ordonnancement
L'ordonnanceur est la partie du noyau qui decide quel thread pret va
etre execute ensuite. Chaque processus a une politique d'ordonnancement
associee et une priorite d'ordonnancement statique, sched_priority.
L'ordonnanceur prend ses decisions en fonction de la politique
d'ordonnancement et de la priorite statique de tous les threads du
systeme.
Pour les threads ordonnances sous l'une des politiques d'ordonnancement
normales (SCHED_OTHER, SCHED_IDLE, SCHED_BATCH), sched_priority n'est
pas utilisee dans les decisions d'ordonnancement (et doit valoir 0).
Les processus ordonnances sous l'une des politiques d'ordonnancement
temps reel (SCHED_FIFO, SCHED_RR) ont une valeur sched_priority dans
l'intervalle 1 (faible) a 99 (haute). (Comme les nombres l'impliquent,
les threads temps reel ont toujours une priorite plus haute que les
threads normaux.) Notez bien : POSIX.1 exige d'une implementation
qu'elle gere seulement un minimum de 32 niveaux de priorite distincts
pour les politiques temps reel et certains systemes n'offrent que ce
minimum. Les programmes portables doivent utiliser
sched_get_priority_min(2) et sched_get_priority_max(2) pour connaitre
l'intervalle des priorites gerees pour une politique particuliere.
Theoriquement, l'ordonnanceur entretient une liste de tous les threads
prets pour l'execution pour chaque valeur possible de sched_priority.
Afin de determiner quel processus doit s'executer ensuite,
l'ordonnanceur recherche la liste non vide de plus haute priorite
statique et choisit le thread en tete de cette liste.
La politique d'ordonnancement d'un thread determine l'emplacement ou il
sera insere dans la liste contenant les threads de meme priorite
statique et comment il se deplacera dans cette liste.
Tout ordonnancement est preemptif : si un thread avec une priorite
statique plus elevee devient pret, le thread actuellement en cours
d'execution est interrompu et retourne dans la liste d'attente avec son
niveau de priorite statique. La politique d'ordonnancement determine
l'ordre utilise seulement dans la liste de threads prets avec des
priorites statiques egales.
SCHED_FIFO : Ordonnancement premier entre, premier sorti
SCHED_FIFO ne peut etre utilisee qu'avec des priorites statiques
superieures a 0, ce qui signifie que des qu'un thread SCHED_FIFO
devient pret, il preempte n'importe quel thread SCHED_OTHER,
SCHED_BATCH ou SCHED_IDLE en cours d'execution. SCHED_FIFO est un
ordonnancement simple sans decoupage temporel. Pour les threads
ordonnances selon la politique SCHED_FIFO, les regles suivantes sont
appliquees :
- Un thread SCHED_FIFO qui a ete preempte par un autre thread de
priorite superieure restera en tete de liste pour sa priorite et
reprendra son execution des que tous les threads de priorite
superieure seront a nouveau bloques.
- Quand un thread SCHED_FIFO bloque devient pret, il est insere en fin
de liste pour sa priorite.
- Si un appel a sched_setscheduler(2), sched_setparam(2),
sched_setattr(2), pthread_setschedparam(3) ou
pthread_setschedprio(3) modifie la priorite du thread SCHED_FIFO
pret ou en cours d'execution, identifie par pid, l'effet sur la
position du thread dans la liste depend de la direction de la
modification de la priorite des threads :
(a) Si la priorite du thread est relevee, il est place en fin de
liste pour sa nouvelle priorite. Par consequent, il peut
preempter un thread en cours d'execution ayant la meme
priorite.
(b) Si la priorite du thread est inchangee, sa position dans la
liste des executions est inchangee.
(c) Si la priorite du thread est abaissee, il est place en tete de
liste pour sa nouvelle priorite.
Selon POSIX.1-2008, les modifications de priorite (ou politique) de
thread en utilisant tout autre mecanisme que pthread_setschedprio(3)
devraient aboutir a ce que le thread soit place en fin de liste pour
sa priorite.
- Un thread appelant sched_yield(2) sera place en fin liste.
Aucun autre evenement ne deplacera un thread ordonnance selon la
politique SCHED_FIFO dans la liste d'attente des threads prets de
priorite statique equivalente.
Un thread SCHED_FIFO s'execute jusqu'a ce qu'il soit bloque par une
requete d'entree-sortie, qu'il soit preempte par un thread de priorite
superieure ou qu'il appelle sched_yield(2).
SCHED_RR : ordonnancement tourniquet
SCHED_RR est une amelioration simple de SCHED_FIFO. Tout ce qui est
decrit pour SCHED_FIFO s'applique aussi a SCHED_RR, sauf que chaque
thread ne dispose que d'un quantum de temps maximal pour son execution.
Si l'execution d'un thread SCHED_RR est d'une duree superieure ou egale
au quantum de temps, il sera place en fin de liste pour sa priorite. Un
thread SCHED_RR qui a ete preempte par un thread de priorite superieure
et par consequent qui reprend l'execution en tant que thread en cours,
terminera la part non utilisee de son quantum de temps dans le
tourniquet. La valeur du quantum de temps peut etre lue avec
sched_rr_get_interval(2).
SCHED_DEADLINE: ordonnancement sur echeances selon le modele des taches
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 tache sporadique presente une sequence de sous-taches qui sont
chacune activees au moins une fois par periode. Chaque sous-tache a
egalement une echeance relative, avant laquelle elle doit achever son
execution, et un temps d'execution qui est le temps CPU necessaire pour
qu'elle s'execute. Le moment auquel une tache est activee parce qu'une
sous-tache doit etre executee est appele temps d'activation (egalement
designe temps d'appel (<< request time >>) ou temps de liberation
(<< release time >>)). Le temps de lancement est le moment auquel la
tache commence son execution. L'echeance imperative est obtenue en
additionnant l'echeance relative et le temps d'activation.
Le schema suivant illustre ces termes :
activation/reveil echeance imperative
| temps du lancement |
| | |
v v v
-----x--------xoooooooooooooooooooooooo--------x--------x---
|<- temps d'execution ->|
|<---------- echeance relative ---------->|
|<----------------- periode ---------------------->|
Lorsqu'une politique SCHED_DEADLINE est activee au moyen de
sched_setattr(2), il est possible de preciser trois parametres :
Runtime, Deadline et Period. Ces parametres ne correspondent pas
forcement aux termes decrits precedemment : il est d'usage d'affecter a
Runtime une valeur superieure au temps d'execution moyen (ou le pire
temps d'execution possible, pour les cas de temps reel extremes) ;
Deadline prend la valeur de l'echeance relative ; enfin, Period recoit
la valeur de la periode de la tache. Ainsi, pour un ordonnancement
SCHED_DEADLINE, on obtient.
activation/reveil echeance imperative
| temps du lancement |
| | |
v v v
-----x--------xoooooooooooooooooooooooo--------x--------x---
|<------- Execution ------->|
|<----------------- Echeance ------------>|
|<----------------- Periode ---------------------->|
Les trois parametres de configuration de l'ordonnancement sur echeances
correspondent aux champs sched_runtime, sched_deadline et sched_period
de la structure sched_attr (consultez sched_setattr(2)). Ces champs
sont exprimes en nanosecondes. Si la valeur 0 est affectee a
sched_period, ce parametre 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 differentes taches n'interferent pas en bloquant
les threads qui tentent de depasser leur temps d'execution (Runtime).
Pour que les conditions requises par l'ordonnancement sur echeances
soient remplies, le noyau doit empecher des situations dans lesquelles
l'ensemble des threads SCHED_DEADLINE n'est pas realisable
(ordonnancement non possible) en tenant compte des contraintes donnees.
Le noyau doit donc executer un test d'approbation lorsque la politique
SCHED_DEADLINE et ses attributs sont definis ou modifies. Ce test
d'approbation valide que le changement demande est realisable ; si ce
n'est pas le cas, sched_setattr(2) echoue et renvoie l'erreur EBUSY.
Par exemple, il est necessaire (et par forcement suffisant) pour
l'utilisation totale d'etre inferieure ou egale au nombre total de CPU
disponibles, ou, puisque chaque thread peut s'executer au plus pour
Runtime par Period, l'utilisation pour ce thread vaut son Runtime
divise par sa Period.
Pour assurer les conditions qui sont requises lorsqu'un thread est
autorise a utiliser la politique SCHED_DEADLINE, les threads
SCHED_DEADLINE ont la priorite la plus elevee parmi tous les threads
(controlable par l'utilisateur) du systeme. Si un thread ordonnance
selon SCHED_DEADLINE est pret, il aura la priorite sur tout autre
thread ordonnance par une autre politique.
Un appel a fork(2) effectue par un thread ordonnance selon la politique
SCHED_DEADLINE echouera en renvoyant l'erreur EAGAIN, sauf dans le cas
ou l'attribut << reset-on-fork >> du thread est active (voir plus bas).
Un thread ordonnance selon SCHED_DEADLINE qui appelle sched_yield(2)
cedera la priorite a la sous-tache en cours et attendra une nouvelle
periode pour debuter.
SCHED_OTHER : ordonnancement temps partage par defaut
SCHED_OTHER peut etre utilise seulement pour la priorite statique 0
(c'est-a-dire que les threads sous politique temps reel ont la priorite
sur les processus SCHED_OTHER). SCHED_OTHER est l'ordonnanceur temps
partage de Linux prevu pour tous les threads n'ayant pas besoin des
mecanismes temps reel speciaux.
Le thread a executer est choisi dans la liste des threads de priorite
statique 0, en utilisant une priorite dynamique qui ne s'applique que
dans cette liste. La priorite dynamique est basee sur la valeur de
politesse (<< nice >>) du thread (voir ci-dessous) et est incrementee a
chaque quantum de temps ou le thread est pret, mais non selectionne par
l'ordonnanceur. Cela garantit une progression equitable de tous les
threads SCHED_OTHER.
Dans le code source du noyau Linux, la politique SCHED_OTHER est en
fait appelee SCHED_NORMAL.
La valeur de politesse
La valeur de politesse est un attribut pouvant etre utilise pour
influencer l'ordonnanceur en faveur ou defaveur 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 etre modifiee avec nice(2), setpriority(2) ou sched_setattr(2).
Selon POSIX.1, la valeur de politesse est un attribut par processus,
c'est-a-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 meme processus
peuvent avoir des valeurs de politesse differentes.
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 meme, le degre auquel la valeur de politesse affecte
l'ordonnancement respectif des processus SCHED_OTHER varie selon les
systemes 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 etre utilisee pour
definir une limite jusqu'a laquelle une valeur de politesse de
processus non privilegie peut etre elevee. Consultez setrlimit(2) pour
les details.
Pour davantage d'explications a propos de la valeur de politesse,
consultez ci-dessous les sous-sections sur la fonctionnalite
d'autogroupe et sur l'ordonnancement de groupe.
SCHED_BATCH : ordonnancement de processus par lots
(Depuis Linux 2.6.16) SCHED_BATCH ne peut etre utilisee qu'avec une
priorite statique de 0. Cette politique est similaire a SCHED_OTHER en
ce qu'elle ordonnance les threads conformement a leur priorite
dynamique (basee sur la valeur de politesse). La difference est que
cette politique fera que l'ordonnanceur considerera toujours que ce
thread demande beaucoup de ressources processeur. Par consequent, il
lui appliquera une petite penalite d'ordonnancement vis-a-vis du
comportement au reveil, ainsi le thread sera legerement desavantage
dans les decisions 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 deterministe sans que
l'interactivite ne cause de preemptions supplementaires (entre les
taches des charges).
SCHED_IDLE : ordonnancement de taches de tres faible priorite
(Depuis Linux 2.6.23.) SCHED_IDLE ne peut etre utilisee qu'avec une
priorite statique de 0 ; la valeur de politesse n'a pas d'influence
pour cette politique.
Cette politique est concue pour l'execution de taches de tres faible
priorite (inferieure meme a une valeur de politesse +19 avec les
politiques SCHED_OTHER ou SCHED_BATCH).
Reinitialiser la politique d'ordonnancement pour les processus enfant
Chaque thread possede un attribut d'ordonnancement reset-on-fork.
Lorsque cet attribut est defini, les enfants crees au moyen de fork(2)
n'heritent pas des politiques d'ordonnancement necessitant des droits.
L'attribut reset-on-fork peut etre defini soit :
- en appliquant un OU logique a l'attribut SCHED_RESET_ON_FORK dans
l'argument policy au moment de l'appel a sched_setscheduler(2) (a
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 a sched_setattr(2).
Notez que les constantes utilisees dans ces deux API ont des noms
differents. La disposition de l'attribut reset-on-fork peut, de facon
analogue, etre obtenue au moyen de sched_getscheduler(2) et de
sched_getattr(2).
La fonctionnalite reset-on-fork est prevue pour des applications de
lecture audiovisuelle et peut etre utilisee pour empecher les
applications de passer outre la limite de ressource RLIMIT_RTTIME
(consultez getrlimit(2)) en creant de nombreux processus enfant.
Plus precisement, si l'attribut reset-on-fork est utilise, les regles
suivantes seront appliquees lors de la creation ulterieure des
enfants :
- Si le thread appelant a une politique d'ordonnancement SCHED_FIFO ou
SCHED_RR, la politique pour les processus enfant est reinitialisee a
SCHED_OTHER.
- Si le processus appelant a une valeur de politesse negative, elle
est mise a zero pour les processus enfant.
Une fois que l'attribut reset-on-fork est active, il ne peut etre
desactive que si le thread possede la capacite CAP_SYS_NICE. Cet
attribut est desactive pour les processus enfant crees avec fork(2).
Privileges 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 specifiques (CAP_SYS_NICE) pour pouvoir
affecter ou modifier la politique SCHED_DEADLINE.
Depuis Linux 2.6.12, la limite de ressources RLIMIT_RTPRIO definit un
plafond pour la priorite statique d'un thread non privilegie pour les
politiques SCHED_RR et SCHED_FIFO. Les regles pour modifier la
politique d'ordonnancement et la priorite sont les suivantes :
- Si un thread non privilegie a une limite souple RLIMIT_RTPRIO non
nulle, il peut modifier sa politique et sa priorite
d'ordonnancement, a condition que la priorite reste inferieure au
maximum de sa priorite actuelle et a sa limite souple RLIMIT_RTPRIO.
- Si la limite souple RLIMIT_RTPRIO est nulle, les seules
modifications permises sont une diminution de la priorite ou bien un
basculement vers une politique qui n'est pas temps reel.
- Soumis aux memes regles, un autre thread non privilegie peut
egalement faire ces modifications a partir du moment ou l'UID
effectif du thread effectuant la modification correspond a l'UID
reel 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 privilegies (CAP_SYS_NICE) ignorent la limite
RLIMIT_RTPRIO : comme avec d'anciens noyaux, ils peuvent modifier
arbitrairement la politique d'ordonnancement et la priorite. Consultez
getrlimit(2) pour plus d'informations sur RLIMIT_RTPRIO.
Limiter l'utilisation CPU des processus temps-reel et a echeances.
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 reel et a echeances qui sont hors de controle.
L'une de ces techniques consiste a utiliser la limite de ressources
RLIMIT_RTTIME pour definir la limite du temps CPU qu'un processus temps
reel a le droit de consommer. Consultez getrlimit(2) pour plus de
details.
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 definit une periode d'ordonnancement correspondant a
100 % de la bande passante du CPU. La valeur contenue dans ce
fichier peut aller de 1 a INT_MAX, soit une duree allant de
1 microseconde a environ 35 minutes. La valeur par defaut
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 reponse
Un thread de haute priorite bloque en attente d'entrees-sorties est
affecte d'un certain temps de reponse avant d'etre selectionne a
nouveau. Le concepteur d'un gestionnaire de peripherique peut reduire
grandement ce temps de reponse en utilisant un gestionnaire
d'interruptions << lentes >>.
Divers
Les processus enfant heritent de la politique d'ordonnancement et des
parametres associes lors d'un fork(2). La politique et les parametres
d'ordonnancement sont conserves au travers d'un execve(2).
Le verrouillage de pages en memoire est generalement necessaire pour
les processus temps reel afin d'eviter les delais de pagination ; cela
peut etre effectue avec mlock(2) ou mlockall(2).
Fonctionnalite d'autogroupage
Depuis Linux 2.6.38, le noyau fournit une fonctionnalite connue comme
l'autogroupage pour ameliorer les performances des bureaux interactifs
confrontes a des charges de travail multiprocessus utilisant enormement
le CPU telles que la construction du noyau Linux avec un grand nombre
de processus de construction en parallele (c'est-a-dire l'indicateur -j
de make(1)).
Cette fonction opere en conjonction avec l'ordonnancement CFS et
necessite un noyau configure avec CONFIG_SCHED_AUTOGROUP. Sur un
systeme en cours d'execution, cette fonctionnalite est activee ou
desactivee a l'aide du fichier
/proc/sys/kernel/sched_autogroup_enabled. Une valeur 0 desactive cette
fonctionnalite tandis qu'une valeur 1 l'active. La valeur par defaut
dans ce fichier est 1 a moins que le noyau ait ete amorce avec le
parametre noautogroup.
Un nouvel autogroupe est cree quand une nouvelle session est creee a
l'aide de setsid(2). Cela se produit, par exemple, quand une nouvelle
fenetre de terminal est demarree. Un nouveau processus cree par fork(2)
herite de l'appartenance d'autogroupe de son parent. Par consequent,
tous les processus dans une session sont membres du meme autogroupe. Un
autogroupe est automatiquement detruit quand le dernier processus du
groupe se termine.
Lorsque l'autogroupage est active, tous les membres d'un autogroupe
sont places dans le meme ordonnanceur << groupe de taches >> du noyau.
L'ordonnanceur CFS emploie un algorithme qui egalise la distribution
des cycles du CPU entre les groupes de taches. Le benefice qui en
decoule pour la performance de bureau interactif peut etre decrit a
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 etre utilise pour modifier la bande passante de
CPU allouee a un autogroupe. Cela peut etre realise en ecrivant un
nombre dans le champ << nice >> du fichier pour definir la valeur de
politesse de l'autogroupe. L'intervalle autorise va de +19 (priorite
basse) a -20 (priorite haute). L'ecriture d'une valeur en dehors de cet
intervalle provoquera l'echec de write(2) avec l'erreur EINVAL.
Le reglage de la politesse de l'autogroupe a la meme acception que la
valeur de politesse du processus, mais s'applique a la repartition des
cycles CPU a un autogroupe dans son ensemble, basee sur les valeurs
relatives de politesse des autres autogroupes. Pour un processus dans
un autogroupe, les cycles CPU qu'il recoit sont deduits de la valeur de
politesse de l'autogroupe (comparee aux autres autogroupes) et de la
valeur de politesse du processus (comparee aux autres processus dans le
meme autogroupe).
L'utilisation du controleur 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 fonctionnalite d'autogroupage groupe seulement les processus
ordonnances selon des politiques non temps reel (SCHED_OTHER,
SCHED_BATCH et SCHED_IDLE). Elle ne groupe pas les processus
ordonnances selon les politiques temps reel et a echeances. Ceux-ci
sont ordonnances selon les regles decrites ci-dessus.
Valeur de politesse et ordonnancement de groupe
Lors de l'ordonnancement de processus non temps reel (c'est-a-dire ceux
ordonnances 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 ete
configure avec l'option CONFIG_FAIR_GROUP_SCHED (ce qui est typique).
Avec l'ordonnancement de groupe, les threads sont ordonnances dans des
<< groupes de taches >>. Celles-ci ont une relation hierarchique, avec
comme racine le groupe de taches initial du systeme connu comme
<< groupe de taches racine >> (root task group). Les groupes de taches
sont constitues dans les circonstances suivantes :
- Tous les threads dans un cgroup du CPU forment un groupe de taches.
Le parent de ce groupe de taches est le groupe de taches du cgroup
parent correspondant.
- Si l'autogroupage est active, alors tous les threads qui sont
(implicitement) places dans un autogroupe (c'est-a-dire la meme
session, telle que creee par setsid(2)) forment un groupe de taches.
Chaque nouvel autogroupe est par consequent un groupe de taches
distinct. Le groupe de taches racine est le parent de tous les
autogroupes de ce type.
- Si l'autogroupage est active, alors le groupe de taches racine se
compose de tous les processus dans le cgroup racine du CPU qui
n'etaient pas par ailleurs places implicitement dans un nouvel
autogroupe.
- Si l'autogroupage est desactive, alors le groupe de taches racine
est constitue de tous les processus dans le cgroup racine du CPU.
- Si l'ordonnancement de groupe a ete desactive (c'est-a-dire que le
noyau a ete configure sans CONFIG_FAIR_GROUP_SCHED), alors tous les
processus du systeme sont en theorie places dans un groupe de taches
unique.
Avec l'ordonnancement de groupe, une valeur de politesse de thread a un
effet sur les decisions d'ordonnancement seulement relatives aux autres
threads dans le meme groupe de taches. Cela a quelques consequences
surprenantes en terme de semantique traditionnelle de la valeur de
politesse sur les systemes UNIX. En particulier, si l'autogroupage est
active (par defaut 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 executes dans la meme
session (classiquement : la meme fenetre de terminal).
Inversement, pour deux processus qui sont (par exemple) les seuls
processus lies a un CPU dans differentes sessions (par exemple, des
fenetres distinctes de terminal, chacune des taches etant liee a un
autogroupe distinct), modifier la valeur de politesse du processus
d'une des sessions n'a pas d'effet en terme de decision
d'ordonnancement relative au processus dans l'autre session. Un
contournement utile possible consiste a 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
Fonctionnalites temps reel 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 etre telecharges a partir de .
Sans les greffons et avant leur complete inclusion dans le noyau
principal, la configuration du noyau n'offre que trois classes de
preemption CONFIG_PREEMPT_NONE, CONFIG_PREEMPT_VOLUNTARY et
CONFIG_PREEMPT_DESKTOP qui fournissent respectivement << aucune >>,
<< quelque >> et une << considerable >> reduction de la pire latence
d'ordonnancement.
Avec les greffons appliques ou apres leur pleine inclusion dans le
noyau principal, la configuration supplementaire CONFIG_PREEMPT_RT
devient disponible. Si elle est choisie, Linux est transforme en un
systeme d'exploitation temps reel ordinaire. Les politiques
d'ordonnancement FIFO et RR sont alors utilisees pour lancer un thread
avec une vraie priorite temps reel et une latence minimale
d'ordonnancement de pire cas.
NOTES
Le controleur cgroups(7) de CPU peut etre utilise 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 francaise de cette page de manuel a ete creee par
Christophe Blaess , Stephan Rafin
, Thierry Vignaud ,
Francois Micaux, Alain Portal , Jean-Philippe
Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas
Huriaux , Nicolas Francois
, Florentin Duneau
, Simon Paillard , Denis Barbier , David Prevot
, Cedric Boutillier ,
Frederic Hantrais et Jean-Paul Guillonneau
Cette traduction est une documentation libre ; veuillez vous reporter a
la GNU General Public License version 3
concernant les conditions
de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE.
Si vous decouvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message a .
Pages du manuel de Linux 6.06 31 octobre 2023 sched(7)