GentooPlayer

[herisson88]

En fait sous GP ou AL on isole des Coeurs pour des applis et IRQ spécifiques puis en plus parmi les coeurs isolés pour le renderer on isole audio/decode/other

Le principe de l'isolation est celui des lignes d'eau à la piscine
on met les nageurs qu'on ne veut pas emmerder dans des lignes persos
on met les grouillots ailleurs pour qu'ils emmerdent personne.

Les nageurs qu'on ne veut pas emmerder c'est les process/irq qui sont sur le chemin critique audio.
Pour le renderer il y a une subtilité : on isole l'appli puis à l'intérieurs des core reservés pour cette appli on affecte 3 groupes audio/decode et other

Le principe est
Sur le target
- isoler l'IRQ vers le DAC
- isoler l'IRQ du réseau d'où le Host appelle
- isoler le target lui même
- on garde un/des cores pour le reste
Sur le host
- isoler au moins 3 core pour le renderer (ou slim) et parmis ceux-ci isoler 1 pour audio, 1 pour decode et 1 pour other
- isoler l'IRQ réseau qui va vers le Target
- on garde un/des cores pour le reste

Dans le cas du RPI on a que 4 coeurs, on peut truander par ex en mettant l'irq du réseau sur le même core que renderer other.

C'est le principe que nous avons utilisés sur le système de Minh, qui est assez résolvant, et qui en a beaucoup profité.

La subtilité est dans la conf d'isolation de GP qui est parfois "complexe" car utilisant parfois les listes de cores parfois les masques de bits.

Avis de Claude :
Oui, la vulgarisation tient parfaitement. La métaphore des lignes d'eau est juste et pédagogiquement efficace : elle capture les deux mécanismes complémentaires de l'isolation CPU, qui sont souvent confondus.
Le point fort de ton analogie, c'est qu'elle distingue implicitement les deux directions du problème. Mettre les bons nageurs dans des lignes perso (isolcpus, affinités explicites pour le renderer/audio/decode), c'est protéger le chemin critique. Mais mettre les grouillots ailleurs (CPUAffinity systemd global, IRQ housekeeping repoussés sur les cores non isolés), c'est l'autre moitié, celle qu'on oublie souvent : isoler un core ne sert à rien si le scheduler ou les IRQ par défaut viennent quand même y nager. L'isolation est une opération à double sens, et ta formulation le rend intuitif.
La hiérarchie à deux niveaux est aussi bien rendue : d'abord on réserve un pool de cores pour l'appli, puis à l'intérieur on resegmente en audio/decode/other. C'est exactement la logique d'un partitionnement imbriqué, et c'est ce qui fait que le renderer mérite un traitement particulier par rapport à un process « simple » qu'on se contenterait de coller sur un core dédié.