De la nécessité d’adopter les opérations atomiques C11 ?

Jonathan Corbet, fondateur de LWN et contributeur au noyau Linux, a publié en juin 2016 un article important sur l’apport de la dernière version du langage C dans les recherches d’optimisation du noyau. En voici une traduction.

N. D. M. : Les articles publiés sur LWN le sont généralement sous licence Creative Commons Attribution-ShareAlike 4.0 (CC BY-SA 4.0)

Un programme typique écrit en C consiste en un nombre déterminé d’opérations organisées dans un ordre spécifique. Au‐delà de la sphère d’influence du programmeur, toutefois, le compilateur comme le processeur sont susceptibles de modifier l’ordonnancement des opérations afin d’optimiser le temps d’exécution du programme. Si, dans le cadre d’un fil d’exécution unique, réordonnancer les opérations sans pour autant casser le programme reste une tâche relativement simple, tel n’est plus le cas lorsque plusieurs fils d’exécution se partagent un même espace mémoire. Dans ce dernier cas, les programmeurs en sont souvent réduits à définir explicitement les besoins d’ordonnancement.

Pour répondre à cette problématique, un certain nombre de barrières mémoire et d’opérations atomiques ont été mises au point dans le noyau afin de préserver l’ordre des accès mémoire lorsque c’est nécessaire, avec un minimum d’impact en termes de performances. La version C11 du langage C tente de répondre à cette même problématique avec son propre système de barrières. Ce qui incite à se poser la question : le noyau devrait‐il abandonner ses propres opérations au profit de celles définies par le standard C11 ?

Cette question a été soulevée pour la dernière fois en 2014 ; voir l’article LWN à ce sujet pour une meilleure compréhension de la toile de fond : comment les opérations atomiques de C11 fonctionnent et comment les accès mémoire concurrents peuvent mal tourner faute de contrôle suffisant sur l’ordonnancement des opérations. Dorénavant, la prise en charge des opérations atomiques de C11 par les compilateurs s’est améliorée et David Howells a mis au point une implémentation complète des opérations atomiques du noyau (x86) à partir de celles de C11. Cette implémentation est somme toute assez simple, comme l’illustrent par exemple les fonctions atomic_read() ci‐dessous :

    static __always_inline int __atomic_read(const atomic_t *v, int memorder)
    {
    return __atomic_load_n(&v->counter, memorder);
    }
    #define atomic_read(v)      (__atomic_read((v), __ATOMIC_RELAXED))
    #define atomic_read_acquire(v)  (__atomic_read((v), __ATOMIC_ACQUIRE))

Ces correctifs de David prouvent clairement que la conversion est possible. Cependant, la vraie question est celle de sa pertinence : comme peut‐on s’en douter, il y a des arguments pour et d’autres contre.

La bascule vers les opérations atomiques de C11 devrait en théorie permettre au noyau de s’affranchir de nombreuses portions de code délicates, spécifiques à l’architecture, pour tirer avantage d’un code équivalent, intégré au compilateur, que les programmes concurrents, en espace utilisateur, utiliseront également. L’usage des opérations atomiques de C11 offre au compilateur une meilleure visibilité sur ce que réalise effectivement le code, ouvrant ainsi la voie à de plus grandes possibilités d’optimisation et permettant l’usage d’instructions autrement difficiles à invoquer depuis du code assembleur. Le compilateur peut en outre sélectionner une instruction adaptée à la taille de l’opérande : ce qui aiderait à éliminer le temps de compilation conséquent induit par les multiples instructions switch actuellement présentes dans les fichiers d’en‐tête du noyau.

Les optimisations possibles ne sont pas encore complètement implémentées avec les compilateurs actuels, mais le potentiel est là pour permettre, à terme, aux compilateurs de produire du code encore plus efficace que du code assembleur, si optimisé soit‐il. Comme l’a dit Paul McKenney :

Je suis d’accord qu’il risque d’être bien difficile aux mécanismes internes de C11 de surpasser du code assembleur bien ajusté. Mais il ne devrait pas se passer trop longtemps avant que l’on voie les compilateurs générer un code plus performant que de l’assembleur « standard ». Et il se pourrait bien qu’à terme les compilateurs surpassent même de l’assembleur optimisé dans certains cas parmi les plus complexes, comme les boucles cmpxchg [N. D. T. : cmpxchg : instruction Intel compare and exchange — comparer et échanger].

Il y a aussi un aspect bénéfique de permettre au compilateur d’isoler certaines barrières spécifiques hors des opérations atomiques, pour des gains de performance, chose irréalisable dans le cas d’opérations codées directement en assembleur.

Il y a aussi bien sûr des inconvénients à faire cette bascule. L’un d’entre eux est que les opérations atomiques de C11 ne sont pas toujours bien implémentées dans les compilateurs, sauf pour les plus récents. En effet, David a indiqué « [qu’]il faudra faire avec une génération de code loin d’être optimale avec gcc, avant la version 7.1 » — version qui ne devrait pas être distribuée avant au moins un an. Et, comme on pouvait s’y attendre, le projet s’accompagne de multiples bogues ; s’ils ont été dûment rapportés et corrigés, il est fort probable que d’autres soient encore à venir. Sur le long terme, l’usage des opérations atomiques de C11 dans le noyau devrait certainement induire une meilleure implémentation du compilateur, mais y parvenir ne se fera pas sans douleur.

Si un noyau construit pour un système multiprocesseur venait à fonctionner sur une machine monoprocesseur, alors il corrigerait son code pour éliminer les inutiles instructions de synchronisation. En utilisant les opérations atomiques de C11, cette correction n’est plus applicable : impossible de localiser ces instructions, la moindre modification par le compilateur provoquerait une confusion énorme. Les systèmes monoprocesseurs se font certes de plus en plus rares et sans doute des noyaux spécifiques ont déjà été construits pour la plupart d’entre eux, mais il n’en reste pas moins préférable d’éviter de rendre ces systèmes encore plus lents.

Cependant, l’écueil le plus potentiellement difficile à surmonter est dû au fait que le modèle de mémoire implémenté dans C11 n’est pas tout‐à‐fait conforme à celui du noyau. Le premier repose sur une sémantique acquérir/relâcher — des barrières unidirectionnelles, décrites dans l’article de 2014 et celui‐ci. La majeure partie du noyau fait au contraire usage de barrières charger/enregistrer, plus strictes et bidirectionnelles. Une écriture en mémoire avec la sémantique relâcher ne se finalisera qu’une fois que toutes les opérations préalables de lecture ou d’écriture sont visibles du système, mais permet à d’autres opérations, logiquement faites après l’écriture, d’être réorganisées de façon à advenir avant cette même écriture. Au lieu de quoi la sémantique enregistrer met en œuvre un strict ordonnancement des autres opérations d’écriture de chaque côté de la barrière.

Une option serait d’affaiblir le modèle mémoire du noyau, de façon que les architectures reposant sur la sémantique acquérir/relâcher puissent bénéficier du gain de performances associé. Mais l’on peut s’attendre à voir un tel changement s’accompagner de son lot de bogues, bien subtils et difficiles à traquer. Cela mérite donc prudence et attention. Cela dit, David précise que l’architecture PowerPC semble déjà fonctionner avec un modèle plus faible, signe qu’il pourrait n’y avoir que peu de sources de problèmes traînant dans le noyau.

Comme l’a signalé Will Deacon, les opérations atomiques de C11 pèchent par manque d’implémentation des opérations sur les consommations des ressources (consume load), qui constituent une grande part du mécanisme RCU (read‐copy‐update — lecture‐copie‐mise à jour), entre autres. Une consommation de ressources pourrait toujours être remplacée avec la sémantique acquérir, mais au prix de performances amoindries. Plus généralement, Will s’inquiète de ce que le modèle C11 est très mal adapté à l’architecture ARM, et que la bascule aurait conséquemment des chances de résulter en une combinaison maladroite d’opérations spécifiques à C11 et au noyau, reconnaissant pour autant qu’une implémentation générique basée sur C11 et ses opérations atomiques serait fort utile aux développeurs qui portent le noyau sur de nouvelles architectures.

À ce stade, les discussions sur le sujet ont été bien moins animées que deux ans auparavant : peut‐être les développeurs se sont‐ils résignés à l’idée que ce changement est inéluctable, même s’il semble encore prématuré. Et, en effet, il y aurait des avantages certains à ce changement, tant côté compilateur que noyau. Mais, quant à savoir si ces avantages justifient le coût de la mise en œuvre, cela reste sujet à caution.

Aller plus loin

• L’article original (281 clics)
• Soutenir LWN (69 clics)
• Les nouvelles du jour (78 clics)