[gull] [SPAM] Re: Truc et astuces: nice et ionice (rappel)]

[Daniel Cordey]

Le 04.03.23 à 13:38, Marc SCHAEFER via gull a écrit :

> Attention, je parle bien d'ionice, et non pas de nice.

Oui, juste, mais je ne vois pas de grande différence. Si un process 
effectue une opération I/O, il va se trouver bloqué et ne sera de toute 
façon pas "élligible". Dès que l'opération I/O descend dans le kernel, 
cette notion de priorité disparaît. On peut au mieux "dégrader" sa 
priorité, mais pas l'améliorer. C'est particulièrement vrai dans le cas 
de "Idle".

> Il ne me semble pas que sur Linux le fonctionnement de nice (et des
> priorités de processus UNIX) ait changé.

Les différents schedulers développés ces dernières années, dans le but 
d'améliorer certaines situations, font donc joujou avec la priorité des 
process. Certains de ces codes privilégient certains I/O au détriment 
d'autres et cela a bien plus d'effets que la priorité d'un process; de 
même ionice aura peu de poids dans ce cas.

Les différentes tentatives d'améliorer les schedulers poursuivent un but 
qu'il est difficile d'atteindre. Il y a un antagonisme entre une station 
de travail et un serveur. Le premier à besoin de "raw" performance sur 
des applications verticales, alors qu'un serveur à besoin de throughput. 
C'est assez irréconciliable :-) En gros, favoriser l'un se fait au 
détriment de l'autre. Les nouveaux schedulers essaient de détecter une 
situation où la nécessité d'interactivité ne sera pas impacté par les 
exigences d'un serveur. Tout ceci est assez complexe (et hors sujet) et 
*nice ont un effet extrêmement limité sur ce que va vraiment faire le 
scheduler.

> C'est juste, mais ici tu parles de la différence entre scheduling UNIX
> classique (sans famine, avec même des processus de priorité inférieure
> qui ont de temps en temps des cycles, donc pas de risque de priority
> inversion [1]), contre scheduling temps réel (RT) qui peut créer des
> famines et des bugs d'inversion de priorité.

Oui, exactement. Le temps réel est quelque chose de spécial, mais qui 
permet d'atteindre un certain niveau de déterminisme, ou de vraiment 
prioriser un process plutôt que d'autres; en évitant le swap et en le 
favorisant dans le scheduler (en agissant au niveau des priorités dans 
les profondeurs du kernel).

> Tu as raison, mais moi je parlais véritablement d'I/O scheduling, une
> extension spécifique à Linux, configurable avec la commande ionice, dans
> la mesure où le backend le support, par exemple bfq. Pas de temps réel.

Oui, effectivement. Même sur un système idle (mon PC), on a un peu plus 
de 1'000 interruptions par seconde et quasi 7'000 context switch par 
seconde. Autant d'occasion de recalculer le process le plus éligible. Il 
y a donc beaucoup de candidats qui vont entrer en compétition avec noter 
process dont on a changé la priorité I/O. Or, avec ionice, on dit "on 
aimerait bien que...", sauf que le scheduler va dire "Oui, mais j'ai la 
cache, le DMA, les drivers... ah oui, toi... un moment". Contrairement à 
ce que l'on pourrait croire, on n'a que peu d'influence avec *nice, sauf 
dans des cas particuliers, mais je dirais certainement pas en mode 
interractif.


> Il n'y a à mon sens aucune raison d'utiliser du RT scheduling, sauf
> applications spéciales à latence garantie (p.ex. traitement audio ou
> autre), et là on va alors séparer entre applications RT spécifiquement
> écrites et laisser nos applications (processus) UNIX en priorité
> classique, car elles ne sont pas forcément prêtes à tous les problèmes
> qui peuvent se poser dans un système RT.

Exact.

> [1] https://fr.wikipedia.org/wiki/Inversion_de_priorit%C3%A9

La première version du kernel HP-UX pour les processeurs PA-RISC était 
"temp réel". A l'arrivé des système multi-processeurs, il a été question 
de récrire la gestion du temps réel en utilisant des sémaphores pour les 
structures du kernel. C'est tombé à l'eau à l'époque. Je ne sais pas 
quelle base est utilisée par Ubuntu pour son kernel temps réel, mais il 
y a toujours eu une base de développement temps réel pour les kernel *X, 
mais c'est plutôt une branche qui évolue en parallèle du kernel standard 
de Linux.

dc