Linux 7.3-rc3 arrive avec des correctifs de sécurité pour XFS et SMB, ainsi qu’une vague de correctifs
Le noyau Linux 7.3 corrige un problème de deadlock et introduit des heuristiques pour limiter le ralentissement quand la VRAM vient à manquer
ce qui a un impact sur les GPU dotés de mémoire vidéo limitée
Le noyau Linux 7.3 apporte des améliorations majeures pour optimiser la gestion de la mémoire vidéo (VRAM). Développées initialement par Natalie Vock chez Valve pour SteamOS, ces nouveautés permettent aux systèmes de mieux supporter l'overcommitment, évitant ainsi les plantages lorsque les jeux dépassent la capacité physique du processeur graphique. Le nouveau code résout un problème de deadlock complexe et introduit des heuristiques de régulation pour empêcher le transfert incessant de données entre la VRAM et la mémoire vive. Grâce à ces optimisations, les performances restent acceptables même en situation de saturation.
Le noyau Linux 7.3 introduit des modifications importantes pour améliorer l'expérience de jeu sur les systèmes disposant d'une mémoire vidéo limitée. Ce travail vise à rendre la saturation de la VRAM beaucoup moins pénalisante, en particulier pour le pilote de cartes graphiques AMDGPU. Auparavant, dépasser la capacité physique de la VRAM provoquait souvent des effondrements de performance majeurs ainsi que des plantages de l'application.
Désormais, le système gère cette surcharge de manière beaucoup plus fluide en permettant au GPU d'accéder plus efficacement à la mémoire système globale. Comme le souligne Natalie Vock : « avec ces correctifs, l'overcommit de la VRAM n'est pas vraiment un problème aussi important qu'on pourrait le penser au premier abord ». Cette optimisation est d'ores et déjà déployée dans les versions stables et préliminaires du SteamOS de Valve.
Contraintes physiques et impact de l'overcommit de la VRAM
Lorsqu'un jeu demande plus de VRAM qu'il n'en existe physiquement, le pilote doit déplacer ou évincer une partie des données vers la mémoire vive classique du processeur. Cependant, pour le processeur graphique, lire des données stockées dans la RAM système s'avère extrêmement lent, car l'accès doit obligatoirement transiter par le bus PCI Express, ce qui limite drastiquement la bande passante disponible et augmente la latence du système.
Par exemple, avec une connexion PCIe 4.0x16, la bande passante maximale utilisable est légèrement inférieure à 32 Go/s, soit environ 32,2 Mo de données transférables par milliseconde. Pour maintenir un affichage fluide à un minimum de 30 images par seconde, le temps d'affichage par image ne doit pas dépasser 33,3 millisecondes, limitant ainsi la quantité absolue de données évincées que le GPU peut récupérer à environ 1 Go par image.
Si le GPU doit lire plus d'un gigaoctet de données par image hors de sa mémoire dédiée, l'objectif des 30 images par seconde devient physiquement impossible à atteindre. Néanmoins, l'impact réel de l'éviction varie considérablement selon la structure des accès à la mémoire et l'utilisation du cache.
Si les données accédées tiennent dans le cache L2 du GPU (qui est de 6 Mo sur une architecture RDNA3), la latence d'accès reste inchangée, que la mémoire sous-jacente se trouve dans la VRAM ou dans la RAM du processeur. Mais un échec de cache obligeant à traverser le bus PCIe se traduit par une latence 7,3 fois plus élevée qu'un accès au cache de niveau supérieur (Infinity Cache) et 4,6 fois plus élevée qu'une lecture directe en VRAM.
Résolution des blocages et intégration de drm_exec dans TTM
Sur le plan de la stabilité, la saturation de la VRAM provoquait jusqu'ici des dysfonctionnements critiques. Le pilote graphique RADV renvoyait régulièrement l'erreur « radv/amdgpu: Not enough memory for command submission », car le noyau signalait une erreur d'absence de mémoire (-ENOMEM) au moment de soumettre les commandes graphiques, alors même que les allocations de ressources initiales avaient été acceptées sans problème.
Cette anomalie s'expliquait par des conflits d'accès dans la gestion des verrous du noyau : à chaque soumission de commande, le pilote AMDGPU doit verrouiller les ressources mémoire référencées par le GPU pour éviter qu'une autre application ne les déplace. Si deux processus concurrents tentaient simultanément d'effectuer des soumissions tout en essayant d'évincer des ressources verrouillées par l'autre, ils se retrouvaient dans une situation d'interblocage réciproque (ou ABBA deadlock).
Bien que le noyau Linux possède un mécanisme robuste de détection et de résolution des interblocages basé sur des boucles d'annulation et de reprise, la bibliothèque de gestion de mémoire partagée pour les GPU, nommée TTM, n'exploitait pas le gestionnaire de verrous standard drm_exec. En adaptant et en corrigeant des correctifs existants pour intégrer drm_exec au sein de TTM, Natalie Vock a réussi à éliminer ces échecs de verrouillage brutaux, transformant les plantages de jeux en de simples ralentissements gérables.
Le problème du ping-ponging et des images de scanout contiguës
Une fois les plantages résolus, les analyses ont révélé une autre anomalie de performance : le ping-ponging de la mémoire. Deux processus gourmands, à l'instar de gamescope et d'un jeu vidéo, passaient leur temps à s'évincer mutuellement les mêmes blocs de données de la mémoire vidéo, ce qui effondrait les performances à un niveau inférieur à celui obtenu si les données n'avaient jamais été déplacées en VRAM.
Le principal coupable de cette instabilité était la mémoire d'affichage liée au scanout. Le matériel d'affichage nécessite que les images destinées à être projetées sur l'écran soient stockées dans un espace physique de la VRAM qui soit entièrement contigu, en contournant l'architecture de mémoire virtuelle du GPU.
Lorsque la mémoire vidéo est saturée et fragmentée, le déplacement d'un espace de scanout hors de la VRAM, suivi de sa réintégration immédiate lors du rafraîchissement d'écran, poussait l'algorithme d'éviction très rudimentaire du noyau à faire de la place par la force. Natalie Vock a constaté que jusqu'à 4 Go de données de VRAM importantes étaient parfois vidés pour faire de la place à une unique image de scanout de seulement 32 Mo, provoquant des pauses de transfert de l'ordre de 130 millisecondes.
Pour corriger ce problème, de nouvelles heuristiques d'attente ont été implémentées. Lors d'une éviction détectée, le pilote entre d'abord dans une phase de « restriction stricte » de quelques millisecondes durant laquelle il s'interdit de rapatrier des données de l'application en VRAM. Il passe ensuite par une phase de « restriction souple » de plusieurs secondes où il réutilise l'espace VRAM qui se libère sans forcer l'éviction de données d'autres applications, avant de lever les restrictions une fois la stabilité retrouvée.
L'étape finale de l'optimisation réside dans la capacité des applications à communiquer directement leurs besoins prioritaires au pilote graphique. Cela s'effectue grâce à l'extension Vulkan « VK_EXT_pageable_device_local_memory » et sa fonction associée « vkSetDeviceMemoryPriorityEXT ». Natalie Vock a connecté ces priorités d'applications à la liste de traitement d'éviction du noyau. Ainsi, au lieu d'évincer des ressources de manière aléatoire ou simplement chronologique, le noyau trie sa liste pour évincer en priorité absolue les blocs mémoire déclarés comme de faible importance par l'application.
Bien que peu de jeux Vulkan natifs intègrent directement cette extension, la couche de compatibilité « vkd3d-proton » (utilisée pour traduire les jeux Direct3D 12 sous Linux) relaie automatiquement les priorités définies par les APIs de Microsoft vers le pilote Vulkan. Cette synergie de priorités rend les performances en cas de surcharge beaucoup plus stables dans le temps et permet des gains de performance allant jusqu'à 30 % dans les scénarios de forte saturation par rapport à une éviction non hiérarchisée.
Résultats pratiques et performances mesurées en jeu
L'efficacité de l'ensemble de ces optimisations a été démontrée à travers des tests poussés sur le jeu « Indiana Jones: The Great Circle». En configurant le titre de manière à solliciter 9 Go de mémoire sur un système équipé d'une carte graphique de 8 Go (soit 1 Go de surcharge stocké dans la RAM système), le jeu est resté parfaitement jouable, affichant un temps de calcul moyen de 19,6 millisecondes par image.
En poussant l'exigence graphique à 10 Go (soit 2 Go de surcharge), la moyenne s'est établie autour de 29,8 millisecondes par image, bien qu'au prix d'une variabilité et de pics de saccades plus marqués. L'expérience globale démontre que malgré la baisse inévitable de performance liée à l'utilisation de la RAM système, le ralentissement reste tout à fait tolérable grâce à une coordination intelligente entre les applications, le pilote graphique et le système d'exploitation.
Les modifications apportées au noyau pour améliorer la gestion de la VRAM devraient être intégrées au noyau Linux 7.3. Natalie Vock poursuit également ses efforts pour apporter encore davantage d’améliorations au comportement de gestion de la mémoire vidéo des pilotes GPU sous Linux.
Qui en bénéficie le plus ?
Ces changements sont particulièrement importants pour deux groupes. Les joueurs équipés de cartes graphiques plus anciennes disposant d’une mémoire vidéo (VRAM) limitée constateront moins de baisses de fréquence d’images lorsqu’ils poussent les paramètres à l’extrême. Les utilisateurs professionnels travaillant avec des textures volumineuses ou des scènes 3D complexes pourront continuer à travailler sans subir de blocages soudains.
Les améliorations sont moins perceptibles sur les cartes graphiques haut de gamme dotées d’une mémoire vidéo abondante, mais même dans ce cas, la nouvelle gestion de la mémoire contribue à prévenir de rares cas limites.
Les compromis à connaître
Le nouveau système n’est pas parfait. Le transfert des tampons vers la mémoire vive du système introduit une latence ; vous pourriez donc constater une légère baisse de performances lorsque la mémoire vidéo est épuisée. Le noyau doit également décider quels tampons dégrader, et il ne fait pas toujours le bon choix. Dans certains cas, vous devrez peut-être encore ajuster les paramètres de l’application pour éviter d’atteindre les limites de la mémoire vidéo dès le départ.
Linux 7.3 n'est qu'une première étape. Les futurs noyaux affineront probablement les politiques d'éviction et amélioreront la coordination entre les pilotes GPU et le sous-système mémoire. Des travaux sont également en cours pour rendre le recours à la mémoire vive du système plus efficace, réduisant ainsi la perte de performances lorsque la mémoire vidéo est épuisée. Pour l'instant, les changements apportés dans la version 7.3 font de Linux une plateforme plus fiable pour les charges de travail gourmandes en graphisme, même sur du matériel plus ancien.
Si vous utilisez un système doté d’une mémoire VRAM limitée, la mise à niveau vers Linux 7.3 en vaut la peine. Ces améliorations ne rendront pas votre GPU plus rapide, mais elles permettront à votre système de rester utilisable lorsque la mémoire viendra à manquer.
Quelques autres nouveautés du noyau Linux 7.3
Toutes les mises à jour relatives aux SoC ont été intégrées au noyau Linux 7.3 ; elles comprennent l’ajout de nouveaux SoC ainsi que la dépréciation de plusieurs anciennes plateformes ARM 32 bits. En conséquence de cette dépréciation, « des centaines » de pilotes se retrouvent désormais orphelins. Parmi les nouveaux SoC ajoutés à l'arborescence principale avec Linux 7.3, on trouve les Apple M3 Pro/Max/Ultra, le Samsung Exynos 1580, le Canaan K210, le Sophgo SG2000, le Qualcomm Shikra et l'Altera Agilex72, qui utilisent tous des cœurs Cortex-A720.
Les joueurs sous Linux qui disposent d'un matériel d'entrée de gamme seront ravis d'apprendre que la mise à jour du planificateur de Peter Zijlstra a enfin été intégrée à Linux 7.3. Cela apporte des améliorations considérables au niveau du « frame pacing », en particulier sur le matériel de la classe « potato ».
Techniquement parlant, il modifie l’EEVDF pour qu’il s’appuie sur une seule file d’attente d’exécution (runqueue) dans certaines situations liées aux cgroups. Cela permet de réduire la fluctuation liée à la replanification, qui a toujours eu un effet plutôt néfaste sur le rythme d’affichage des images (frame pacing) sur le matériel bas de gamme et de dernière génération. Comme mentionné précédemment, les résultats sont assez impressionnants.
Lors de tests sur un système équipé de ce qui semble désormais être un processeur Intel Sandy Bridge (Core i7 2600K) préhistorique, associé à une carte graphique AMD Radeon RX 580 Polaris, la logique de planification améliorée susmentionnée a montré des gains de performances prometteurs lors de tests de performance sous charges intensives. Les temps d'affichage ont également connu une hausse spectaculaire (image ci-dessus).
Les véritables passionnés de Linux savent que l'adoption des modifications dans le noyau principal est un processus plutôt lent. Cependant, CachyOS, la distribution basée sur Arch qui privilégie les performances, a déjà annoncé que ces modifications seraient bientôt intégrées, même si aucun délai précis n'a été communiqué.
Source : billet de blogue
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi
Répondre avec citation
Partager