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 _______________________________________________ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
