Linux 5.16 a pris une semaine de plus que prévu initialement. Linus Torvalds a décidé de donner au noyau un peu plus de temps pour mûrir. Cette décision n’a pas été motivée par des problèmes ou des résultats de test alarmants, mais simplement par la crainte que les tests ne soient trop courts en raison des fêtes de fin d’année et de la semaine « entre les deux ».

En fait, il n’y a pas eu de changements majeurs au cours de la semaine supplémentaire de rc8. Le nouveau noyau a vu le jour dans la nuit de dimanche à lundi et était plutôt attendu comme une version de maintenance. Néanmoins, la 5.16 offre quelques nouveautés intéressantes comme l’entrée dans futex2, l’alerte active des erreurs du système de fichiers au niveau du noyau, un ordonnanceur CPU « conscient des clusters » et une sécurité accrue. Le nouveau noyau s’attaque également à une tâche gigantesque par le biais de folio-pages pour une gestion efficace et plus performante de la mémoire.

Des jeux plus rapides grâce à futex2

Linux 5.16 donne le coup d’envoi de futex2 et promet de meilleures performances, notamment pour l’émulation de jeux Windows. futex2 doit remplacer à terme l’appel système futex(), qui a pris de l’âge et s’est développé historiquement. Futex est l’abréviation de « Fast User Mutex ». Il permet d’utiliser des mutexes, c’est-à-dire des blocages pour l’accès concurrent, non seulement dans l’espace du noyau mais aussi dans l’espace utilisateur.

Le concept a été introduit dès 2003 dans le noyau 2.6.0 sous la forme de l’appel système futex(). La première application centrale de l’appel système a été le contrôle de l’exécution secondaire des threads POSIX. Auparavant, les processus en espace utilisateur ne pouvaient s’appuyer que sur des sémaphores, par exemple via eventfd(), pour accéder aux ressources partagées.

Les sémaphores offrent un mécanisme permettant de « signaler » les ressources devenues libres. Un processus ou un thread en attente d’une ressource qui se libère vérifie régulièrement si l’accès est désormais possible. Les mutex, en revanche, bloquent les ressources jusqu’à ce qu’elles soient à nouveau disponibles. Un appel à futex() bloque le processus ou le thread jusqu’à ce que la ressource concernée soit libérée. Les mutexes sont donc en principe plus légers dans l’application et plus gourmands en ressources CPU dans le noyau que les sémaphores.

Historiquement : futex()

La popularité de futex() fait que l’appel système est utilisé dans de nombreux scénarios d’application. C’est pourquoi les appels à une ré-ingénierie de l’appel se sont multipliés, afin d’obtenir des fonctions individuelles ou au moins des enveloppeurs dans la libc, en fonction des cas d’utilisation. En réponse, l’approche futex2 d’André Almeida a été lancée il y a environ deux ans, avec pour objectif de créer un sous-système futex flexible.

Même dans Linux 5.16, futex2 est encore loin de remplacer l’ancien futex(). L’approche adoptée est une variante légère qui répond à un problème spécifique. L’ancien futex() est limité dans sa fonction. Elle ne peut interroger qu’un seul futex. Si plusieurs sont à prendre en compte, cela ne peut se faire que l’un après l’autre. Avec le défaut d’exécuter plusieurs appels bloquants de futex() en série. Cela présente des inconvénients, notamment pour les jeux Windows portés qui utilisent des couches d’émulation comme WINE ou Steam Play de Proton.

Mimétisme de l’API Windows

L’API Windows propose la fonction WaitForMultipleObjects() qui permet d’interroger plusieurs objets. Ces objets peuvent être utilisés de la même manière que les ressources et les futexes dans Linux. Windows peut cependant effectuer la requête en parallèle en un seul appel. Linux ne l’a pas fait jusqu’à présent. C’est là qu’intervient Linux 5.16 avec le premier patch futex2. Le noyau introduit l’appel système futex_waitv() qui – contrairement à futex() – peut attendre plusieurs mutex ou leur libération. Ainsi, Linux 5.16 peut reproduire WaitForMultipleObjects() dans les couches d’émulation de manière plus élégante et efficace. Les jeux portés bénéficient d’un gain de vitesse.

André Almeida voit peut-être le potentiel d’accélérer également les jeux Linux natifs à l’aide du nouvel appel système : « Les moteurs de jeux natifs en profiteront également, à condition que ce modèle Wait soit courant pour les jeux ». Une documentation sur futex2 et futex_waitv() est disponible dans les sources du noyau décompressées sous Documentation/userspace-api/futex2.rst, ou bien dans le patch concerné.