isolcpus laisse des cœurs inactifs mais les IRQ les sollicitent
Même la technique d’isolation CPU la plus simple peut induire en erreur. Configurer isolcpus=0,1 dans GRUB et redémarrer fait apparaître ces cœurs vides dans top, mais les interruptions matérielles ignorent cette indication. Les demandes d’interruption (IRQ) continuent de cibler les cœurs isolés, les empêchant de rester véritablement inactifs. Si l’objectif est un traitement par scrutation précise, un pilote utilisateur pour carte réseau ou un traitement de paquets à la manière de DPDK, l’isolation du planificateur ne suffit pas.
Le mur à moitié visible entre cœurs et interruptions
Après un redémarrage avec isolcpus=0,1, de nombreux administrateurs vérifient /proc/cmdline et exécutent taskset -cp 1 sur un PID de processus connu pour confirmer l’isolement. Le piège consiste à observer top ou htop au lieu de /proc/interrupts. Une commande rapide watch -n1 'grep "^ *[0-9]" /proc/interrupts | head' révèle le trafic caché : les compteurs d’IRQ continuent d’augmenter sur le CPU0 et le CPU1. Ce trafic peut préempter le fil d’exécution verrouillé, détruire le déterminisme ou fausser les résultats de benchmark.
Noyaux modernes, habitudes dépassées
Les noyaux récents proposent des alternatives — isolcpus=domain, les groupes de contrôle cpuset ou managed_irq — mais l’écueil des IRQ persiste. Le flag isolcpus= longtemps obsolète apparaît encore dans des exemples de configuration GRUB et des tutoriels rapides. Même lorsqu’il est remplacé par les cpusets ou nohz_full=, la nécessité de gérer l’affinité des IRQ subsiste. Les administrateurs doivent explicitement rediriger les IRQ vers d’autres cœurs en écrivant dans /proc/irq/IRQNUM/smp_affinity ou en définissant irqaffinity=2-7 dans la même ligne GRUB. Certains périphériques ignorent ces modifications, nécessitant des astuces au niveau du pilote comme l’association des cartes réseau à vfio-pci et le verrouillage des fils de scrutation.
Vérifiez avec les interruptions, pas avec top
Une machine dédiée aux chemins de données optimisés pour une faible latence combine généralement l’IOMMU activée (intel_iommu=on iommu=pt), les fonctions virtuelles SR-IOV et des fils d’exécution utilisateur verrouillés. La vérification finale passe par /proc/interrupts, et non par top. Si les compteurs d’IRQ continuent d’incrémenter sur les cœurs censés être isolés, l’isolement est incomplet — et la charge ne respectera pas le budget de cycles attendu.
Pourquoi est-ce important
Pour les charges de travail en temps réel ou de traitement de paquets, l’isolation du planificateur n’est qu’une première étape. Les interruptions matérielles peuvent discrètement reprendre la main sur le CPU, brisant le déterminisme et augmentant la latence. Les administrateurs qui se fient à isolcpus sans vérifier le placement des IRQ risquent de déployer des systèmes semblant inactifs alors qu’ils traitent des interruptions cachées. La leçon à retenir : considérez isolcpus comme un point de départ, non comme une solution complète, et vérifiez toujours avec /proc/interrupts avant de faire confiance à la disponibilité d’un cœur.
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.