On Sat, Mar 04, 2023 at 01:17:00PM +0100, Daniel Cordey via gull wrote: > Le 04.03.23 à 12:46, Marc SCHAEFER via gull a écrit : > > > Soit c'est psychologique, soit ça rend effectivement les I/O plus > > souples dans mon workload et refait marcher l'ionice. > > nice a subsisté dans les différentes version UNIX (AIX, HP-UX, Solaris),
Attention, je parle bien d'ionice, et non pas de nice. Il ne me semble pas que sur Linux le fonctionnement de nice (et des priorités de processus UNIX) ait changé. > Si l'on veut vraiment avoir un impact sur le niveau de priorité des > processus et que cela ait un effet réel, il faut utiliser un kernel > Real-Time, entre autre disponible comme une LTS spéciale chez Ubuntu > (actuellement 22.04 LTS) et décrit ici : 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é. 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. > "Ce n'est pas parce qu'une nouvelle technologie existe qu'il faut > l'utiliser" 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. [1] https://fr.wikipedia.org/wiki/Inversion_de_priorit%C3%A9 _______________________________________________ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
