Les méta-ingénieurs ont proposé une fonctionnalité”swqueue”de file d’attente de travail partagée pour le planificateur CFS du noyau Linux qui peut aider à une légère amélioration des performances de débit et à une latence légèrement meilleure, en particulier pour les systèmes AMD avec plusieurs CCX.
Une”demande de commentaires”a été publiée aujourd’hui sur cette fonctionnalité CFS swqueue sur laquelle les ingénieurs de Meta ont travaillé. Dans leur cas, ils ont été amenés à travailler sur swqueue pour améliorer l’ensemble des serveurs AMD EPYC exécutant des processus de serveur Web HHVM pour Facebook.
Certains des principaux points à retenir de leur lettre d’accompagnement du correctif RFC sont :
Nous avons remarqué que les processeurs étaient toujours inactifs même lorsque l’hôte était surchargé. En réponse, nous avons écrit la fonctionnalité”shared wakequeue”(swqueue) proposée dans cet ensemble de correctifs. L’idée derrière swqueue est simple : elle permet au planificateur d’économiser du travail de manière agressive en plaçant une tâche de réveil dans une file d’attente FIFO par LLC qui peut être extraite d’un autre cœur de la file d’attente FIFO LLC qui peut ensuite être extraite avant qu’elle ne parte inactif.
Grâce à ce simple changement, nous avons pu obtenir une amélioration de 1 à 1,6 % du débit, ainsi qu’une légère amélioration constante des latences p95 et p99, dans HHVM. Ces améliorations de performances s’ajoutaient aux gains des boutons de débogage mentionnés ci-dessus.
…
L’amélioration d’environ 1 à 1,6 % du débit HHVM est également visible en utilisant des planificateurs sched_ext qui conservent le travail (même ceux très simples comme le FIFO global).
Dans les hôtes mono et multi socket/CCX , cela peut améliorer sensiblement les performances. Outre les gains de performances observés sur nos charges de travail Web internes, nous avons également observé une amélioration des charges de travail courantes telles que la compilation du noyau lors de l’exécution d’une file d’attente partagée.
…
swqueue sous cette forme semble apporter un gain modeste mais notable pour les charges de travail liées au processeur frontal réparties sur plusieurs CCX. La raison semble assez simple : swqueue encourage la conservation du travail à l’intérieur d’un CCX en demandant à un processeur d’effectuer une extraction O(1) à partir d’une file d’attente par LLC de tâches exécutables. Comme mentionné ci-dessus, il est complémentaire de SIS_NODE, qui recherche les cœurs inactifs sur le chemin de réveil.Bien que swqueue sous cette forme encourage la conservation du travail, cela ne le garantit bien sûr pas étant donné que nous ne mettons en œuvre aucun type de vol de travail entre swqueues. À l’avenir, nous pourrions potentiellement pousser l’utilisation du processeur encore plus haut en permettant le vol de travail entre les swqueues, probablement entre les CCX sur le même nœud NUMA.
L’ensemble de correctifs swqueue est un peu plus de 200 lignes de nouvelles code et les correctifs RFC sont maintenant disponibles pour examen sur la liste de diffusion du noyau.
