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

[Marc SCHAEFER]

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