Plus tôt ce mois-ci, j’ai remarqué un changement de planificateur Linux mis en file d’attente dans sched/core avant le cycle Linux 5.18 qui est devrait aider les processeurs AMD EPYC et d’autres processeurs Zen sélectionnés dans diverses charges de travail. Le changement est en préparation depuis plusieurs mois et consiste à ajuster le déséquilibre NUMA autorisé lorsqu’il s’étend sur plusieurs LLC. J’ai maintenant effectué certains de mes propres tests de performances sur le matériel EPYC et en effet, j’augmente encore les performances du noyau Linux.
Le correctif annonce de beaux gains de performances… Maintenant, je teste de mon côté.
Ce changement mis en file d’attente dans”sched/core”avant la fenêtre de fusion Linux 5.18 du mois prochain n’est pas un changement spécifique à AMD, mais un changement qui profite aux processeurs Zen en raison de leur disposition de cache. Mel Gorman, auteur du correctif, a expliqué :”[Un changement du planificateur du noyau à partir de 2020] a permis un déséquilibre entre les nœuds NUMA, de sorte que les tâches de communication ne seraient pas séparées par l’équilibreur de charge. Cela fonctionne bien lorsqu’il existe une relation 1:1 entre LLC et nœud, mais peut être sous-optimal pour plusieurs LLC si des tâches indépendantes utilisent prématurément le cache de partage des processeurs.Zen * a plusieurs LLC par nœud avec des canaux de mémoire locaux et en raison du déséquilibre autorisé, il est beaucoup plus difficile de régler certaines charges de travail pour qu’elles fonctionnent de manière optimale que sur matériel qui a 1 LLC par nœud. Ce correctif permet à un déséquilibre d’exister jusqu’au point où les LLC doivent être équilibrées entre les nœuds.”
Peut confirmer une excellente amélioration des performances sur la série EPYC 7003 à travers une variété des charges de travail avec les derniers changements de programme/noyau TIP.
Les propres benchmarks de Mel lors du travail sur ce patch ont vu une amélioration allant jusqu’à 272 % pour le benchmark de mémoire Stream et également d’autres gains importants comme 10 % de meilleures performances dans Coremark et un maximum imum jusqu’à 17 %, les performances de SPECjbb Java ont augmenté de 18 %, le benchmark parallèle embarrassant de NPB était d’environ 17 % plus rapide et d’autres gains notables. Compte tenu des résultats très prometteurs rapportés, j’ai effectué certains de mes propres tests localement et les chiffres que je vois sont tout aussi excitants-en particulier pour ce changement de planificateur du noyau Linux qui n’est que d’environ 50 lignes de nouveau code !
Tout d’abord, voici quelques benchmarks exécutés avec un serveur AMD EPYC 75F3 2P construit autour d’une carte mère ASRockRack ROME2D16-2T et exécutant Ubuntu 21.10. Les performances ont été comparées entre Linux 5.17 Git et ensuite sched/core Git ayant le correctif « sched/fair: Ajuster le déséquilibre NUMA autorisé lorsque SD_NUMA s’étend sur plusieurs LLCs » en question. Le même noyau Kconfig entre les deux noyaux a été utilisé.