Juste pour dire qu'il ne s'agit plus d'un patch, depuis un an ou deux, c'est dans le noyau vanilla.
Il faut ajouter l'option à la compilation du noyau, mais plus besoin de le patcher.
J'ai fait du Realtime avec une Slackware current, en ajoutant cette option avant de recompiler le noyau standard de la distrib.
J'en avais profité, à fins de tests, pour supprimer les mitigations SPECTRE et autres qui affectent entre autre les Xeon un peu vétustes, j'avais 35% en gain de latence.
Au prix de failles de sécurité béantes, est-ce si cher payé ..? ;)
Enfin, tout ça pour dire que le realtime Linux, c'est vraiment à la portée de tout le monde.
Maintenant, il faut que ça serve à quelque chose. Et sur un poste de travail, à part pour de la musique, gérer une latence minimale sur certains points précis, ça a peu d'utilité.
Cet article mentionne que PREEMPT_RT améliore la latence aux dépends du débit, mais ne donne pas de chiffres sur l'impact en pratique.
Dans un de mes projets, on avait essayé d'activer PREEMPT_RT, et on a constaté que dans notre cas, la dégradation des performances n'était pas acceptable. On s'est donc débrouillés autrement (avec des modifications dans le firmware du matériel avec lequel on s'interface) pour ne plus avoir de contraintes temps réel fortes sur le système Linux.
Donc, ça fonctionne, mais ce n'est peut-être pas la meilleure solution, dans certains cas un système pensé dès le départ pour le temps réel sera peut-être meilleur (je n'ai pas encore eu l'occasion de faire de comparaisons).
Par contre, l'article mentionne directement des solutions propriétaires. Dommage pour RTEMS et FreeRTOS et sûrement quelques autres projets dans ce domaine, qui font du temps réel open source depuis fort longtemps.
Je ne connais pas ton cas d'usage, ni vraiment ce que tu entends par débit.
Par contre, pour faire « correctement » du RT, il faut des paramétrages plus compliqués.
Sans plus d'explication que ça, on obtient les meilleurs résultats RT avec des trucs comme ça :
- Couper l'hyperthreading dans le BIOS ;
- Isoler certains cœurs, pour qu'ils ne servent jamais pour aucune tâche, sauf si demandé explicitement ;
- Ajouter idle=poll en option du noyau, ça laisse tourner les cœurs quand ils ne font rien, autant dire que côté consommation, c'est assez mauvais ;
- D'autres options à l'utilité obscure, mais dont on trouve la recommandation dans des papiers de recherche de chez Intel à ce sujet, comme audit=0, nmi_watchdog=0, acpi_irq_nobalance, processor.max_cstate=0, mce=ignore_ce, rcu_nocb_poll.
J'ai compris l'utilité de ces options au moment de chercher, et en lisant les docs qui expliquaient pourquoi, mais c'est rapidement ressorti.
Et comme ça, tu peux avoir du Realtime avec une bonne latence (<50µs, et en pratique on peut descendre sous les 20µs, et on gagne environ 30-35% sur la même machine avec une VM qui ignore les mitigations des failles de sécurité des XEONs), même en machine virtuelle (KVM, core-pinning avec SCHED_FIFO pour les cœurs de ta VM, sur des cœurs isolés).
Sur un Xeon on obtient de bien meilleurs résultats (plus stable, meilleure latence moyenne, latence maximale plus basse) que sur un Intel classique (i3/5/7…), et je n'ai pas de comparaison avec des processeurs AMD, ou avec des ARMs.
Donc l'architecture du CPU joue aussi.
De loin, je dirais que si tu gères bien tes cœurs, et que tu n'utilises jamais les cœurs hyperthreadés d'un cœur utilisé pour le RT, ça devrait ne pas avoir d'impact, mais c'est purement subjectif au nez mouillé, comme appréciation.
Par exemple, tu as 8 cœurs (0-7 + 8-15 avec l'hyperthreading), tu en réserves 4 au RT, donc tu isoles 4-7 et 12-15, tu as 4 cœurs et 4 autres hyperthreadés sur 0-3 et 8-11 pour ton système, les tâches non-RT, etc. Et tu as 4 cœurs RT (4-7), et tu n'utilises jamais les « versions hyperthreadées » de ces cœurs (12-15).
Mais bon, tout va toujours dépendre de tes besoins réels.
Si realtime pour toi c'est <1000µs, tu peux être plus lâches dans les options, et avoir un système global mieux géré, plus réactif, tout en ayant des tâches RT « suffisantes ».
S'il te faut vraiment une très faible latence, alors c'est difficile d'avoir une machine multi-utilité qui va en plus réussir à tenir le temps réel dont tu as besoin.
Et si en plus tu cherches une isolation forte avec des VMs, tu contrains encore plus.
# Patch PREEMPT_RT
Posté par Yth (Mastodon) . Évalué à 3 (+1/-0).
Juste pour dire qu'il ne s'agit plus d'un patch, depuis un an ou deux, c'est dans le noyau vanilla.
Il faut ajouter l'option à la compilation du noyau, mais plus besoin de le patcher.
J'ai fait du Realtime avec une Slackware current, en ajoutant cette option avant de recompiler le noyau standard de la distrib.
J'en avais profité, à fins de tests, pour supprimer les mitigations SPECTRE et autres qui affectent entre autre les Xeon un peu vétustes, j'avais 35% en gain de latence.
Au prix de failles de sécurité béantes, est-ce si cher payé ..? ;)
Enfin, tout ça pour dire que le realtime Linux, c'est vraiment à la portée de tout le monde.
Maintenant, il faut que ça serve à quelque chose. Et sur un poste de travail, à part pour de la musique, gérer une latence minimale sur certains points précis, ça a peu d'utilité.
[^] # Re: Patch PREEMPT_RT
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
Cet article mentionne que PREEMPT_RT améliore la latence aux dépends du débit, mais ne donne pas de chiffres sur l'impact en pratique.
Dans un de mes projets, on avait essayé d'activer PREEMPT_RT, et on a constaté que dans notre cas, la dégradation des performances n'était pas acceptable. On s'est donc débrouillés autrement (avec des modifications dans le firmware du matériel avec lequel on s'interface) pour ne plus avoir de contraintes temps réel fortes sur le système Linux.
Donc, ça fonctionne, mais ce n'est peut-être pas la meilleure solution, dans certains cas un système pensé dès le départ pour le temps réel sera peut-être meilleur (je n'ai pas encore eu l'occasion de faire de comparaisons).
Par contre, l'article mentionne directement des solutions propriétaires. Dommage pour RTEMS et FreeRTOS et sûrement quelques autres projets dans ce domaine, qui font du temps réel open source depuis fort longtemps.
[^] # Re: Patch PREEMPT_RT
Posté par Yth (Mastodon) . Évalué à 9 (+7/-0).
Je ne connais pas ton cas d'usage, ni vraiment ce que tu entends par débit.
Par contre, pour faire « correctement » du RT, il faut des paramétrages plus compliqués.
Sans plus d'explication que ça, on obtient les meilleurs résultats RT avec des trucs comme ça :
- Couper l'hyperthreading dans le BIOS ;
- Isoler certains cœurs, pour qu'ils ne servent jamais pour aucune tâche, sauf si demandé explicitement ;
- Ajouter idle=poll en option du noyau, ça laisse tourner les cœurs quand ils ne font rien, autant dire que côté consommation, c'est assez mauvais ;
- D'autres options à l'utilité obscure, mais dont on trouve la recommandation dans des papiers de recherche de chez Intel à ce sujet, comme audit=0, nmi_watchdog=0, acpi_irq_nobalance, processor.max_cstate=0, mce=ignore_ce, rcu_nocb_poll.
J'ai compris l'utilité de ces options au moment de chercher, et en lisant les docs qui expliquaient pourquoi, mais c'est rapidement ressorti.
Et comme ça, tu peux avoir du Realtime avec une bonne latence (<50µs, et en pratique on peut descendre sous les 20µs, et on gagne environ 30-35% sur la même machine avec une VM qui ignore les mitigations des failles de sécurité des XEONs), même en machine virtuelle (KVM, core-pinning avec SCHED_FIFO pour les cœurs de ta VM, sur des cœurs isolés).
Sur un Xeon on obtient de bien meilleurs résultats (plus stable, meilleure latence moyenne, latence maximale plus basse) que sur un Intel classique (i3/5/7…), et je n'ai pas de comparaison avec des processeurs AMD, ou avec des ARMs.
Donc l'architecture du CPU joue aussi.
De loin, je dirais que si tu gères bien tes cœurs, et que tu n'utilises jamais les cœurs hyperthreadés d'un cœur utilisé pour le RT, ça devrait ne pas avoir d'impact, mais c'est purement subjectif au nez mouillé, comme appréciation.
Par exemple, tu as 8 cœurs (0-7 + 8-15 avec l'hyperthreading), tu en réserves 4 au RT, donc tu isoles 4-7 et 12-15, tu as 4 cœurs et 4 autres hyperthreadés sur 0-3 et 8-11 pour ton système, les tâches non-RT, etc. Et tu as 4 cœurs RT (4-7), et tu n'utilises jamais les « versions hyperthreadées » de ces cœurs (12-15).
Mais bon, tout va toujours dépendre de tes besoins réels.
Si realtime pour toi c'est <1000µs, tu peux être plus lâches dans les options, et avoir un système global mieux géré, plus réactif, tout en ayant des tâches RT « suffisantes ».
S'il te faut vraiment une très faible latence, alors c'est difficile d'avoir une machine multi-utilité qui va en plus réussir à tenir le temps réel dont tu as besoin.
Et si en plus tu cherches une isolation forte avec des VMs, tu contrains encore plus.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.