DragonFly est un système d’exploitation de type UNIX, issu d’un fork de la branche 4._x_ de FreeBSD, il y a maintenant presque 10 ans. Initialement, le but était d’arriver à un système d’exploitation pour grappe de serveurs — cluster — et, entre autres, de garantir la cohérence de cache au niveau du système d’exploitation, pour permettre à plusieurs applications de tourner sur une multitude de machines dans un même environnement logiciel. Bien que ce ne soit plus le but premier, ce concept a influencé et continue d’influencer l’architecture du noyau.

Cette dépêche a été rédigée en collaboration avec d-jo, EggMan, bastien, Nÿco et Neox. Merci à tous les participants.

• lien n°1 : Notes de version de DragonFly 3.2
• lien n°2 : Site officiel du projet
• lien n°3 : Page de téléchargement
• lien n°4 : L’annonce de la disponibilité des images

Sommaire

• DragonFly 3.2
  • Noyau
    • Nouvel ordonnanceur
    • Virtual memory : optimisation de la mémoire partagée pour x86_64
    • Autres optimisations SMP
    • Pile USB
    • Systèmes de fichiers
      • puffs
      • vquota
      • tmpfs
    • pilotes et réseau
  • Espace utilisateur
    • GCC 4.7
    • Éditeur de liens dynamiques
    • Divers
    • Paquets
  • Qualité du code
• Projets
  • Hammer2
  • bmake
  • inotify
• Desktop

DragonFly 3.2

Le 21 octobre, la version 3.2.1 de DragonFly a été étiquetée dans le dépôt git, 6 mois après la version 3.0.1, sortie en février 2012. Les ISO officielles sont désormais disponibles depuis le 2 novembre sur les miroirs du projet. La suite de la dépêche présente une partie des nouveautés de cette version, ainsi que certains projets à plus long terme.

Noyau

Nouvel ordonnanceur

L’ordonnanceur est le code qui sert à répartir les ressources processeur aux threads qui tournent sur le système. Jusqu’à présent le user mode scheduler était une version un peu modifiée de l’ordonnanceur de BSD 4.4. Il fonctionne avec une file d’exécution par niveau de priorité, le nombre de niveaux de priorité étant fixé. Quand un thread est exécutable, il est placé dans la file correspondant à sa priorité. Le problème de ce code est qu’il avait été écrit dans une optique monocœur. Les files sont protégées par un spinlock, et sont globales (c’est‐à‐dire communes à tous les processeurs), ce qui pose des problèmes de contention.

Dans un premier temps, Mihai Carabas a travaillé durant un GSoC à un framework permettant à l’ordonnanceur de tenir compte de la topologie des CPU (c’est-à-dire de l’agencement des sockets/cores/threads), de manière similaire à ce qui existe dans le noyau Linux. Ce message résume sa contribution, qui consiste en 3 principaux points :

• L’ajout de code pour détecter la topologie de la machine
• Une heuristique qui essaie de faire exécuter les threads d’abord sur les cœurs libres puis sur les threads (dans le sens Hyper Threading) du CPU, ce qui a pour effet de rendre les temps d’exécution plus constants, quand le nombre de threads s’exécutant est inférieur au nombre de cœurs. Un exemple avec openssl sur un bi-xeon 12 cœurs/24 threads
• Une heuristique pour tenter d’améliorer l’effet du cache pour les threads nécessitant beaucoup de CPU, en tentant de les réordonnancer sur le même thread/core/CPU (au choix).

Mais les choses ne se sont pas arrêtées là. Lors de tests consécutifs à ce travail, l’exécution de pgbench sur une Xeon 12x2 (24 thread) a montré des problèmes de passage à l’échelle. Matt Dillon a donc écrit un nouvel user mode scheduler, partiellement basé sur l’ancien, mais avec une logique plus adaptée à un environnement multiprocesseur.

Tout d’abord, les run-queues ne sont plus globales, mais par CPU, ce qui supprime le spinlock global et permet de réduire la contention. Pour reprendre les mots de Matt Dillon,

Le nouvel ordonnanceur contient une réécriture des algorithmes se basant sur la topologie des CPU pour mettre en place une méthode d’ordonnancement verticale (Machine → socket → cœur → hyperthread), essentiellement par 3 mécanismes :

1. il calcule un facteur de charge pour chaque niveau de la topologie, et équilibre les processus assignés aux CPU selon ce facteur en tenant compte de la topologie. Cela signifie que 4 processus s’exécutant dans un environnement 4x2 (8 threads) seront assignés aux 4 cœurs et non à des hyperthreads d’un même cœur.
2. il essaye d’éviter de migrer des processus quand c’est possible, et si ce n’est pas le cas, il essaye de les garder proches au sens topologique.
3. il détecte les événements de type blocage/réveil des processus qui, par exemple, associent deux processus et essaye de déplacer les deux éléments de la paire plus près l’un de l’autre, en utilisant ces informations. Par exemple, s’il y a beaucoup de clients et de serveurs PostgreSQL sur une grosse machine, assez pour charger tous les cœurs, les couples clients/serveurs s’exécuteront sur les mêmes sockets, ce qui permet d’utiliser les caches des processeurs pour les communications interprocessus.

Les gains de ce travail sont immenses, comme le montre le test de performances globales présenté plus bas. Ils ont un impact sur différentes charges, comme par exemple la compilation du noyau.

Virtual memory : optimisation de la mémoire partagée pour x86_64

Les tests de passage à l’échelle avec pgbench ont montré un goulot d’étranglement dans la gestion des segments de mémoire partagée de grande taille qu’ils soient obtenus par SYSV SHM ou MMAP. En effet, quand un processus effectue un fork, chaque processus doit passer par un grand nombre de page faults. Quand de nombreux processus effectuent un fork, comme c’est le cas dans les tests pgbench, il s’agit de millions de page faults. En outre, les page tables sont dupliquées.

Pour comprendre cette optimisation, une vue d’ensemble du fonctionnement de la mémoire virtuelle sous DragonFlyBSD est nécessaire. Si vous êtes intéressés, ce vieil article explique le fonctionnement général de la mémoire virtuelle.


Pour éviter ces problèmes, quand un vm_object est assez grand, la partie de la page table concernée est stockée dans l’objet lui-même et non dans le pmap du processus. De ce fait, les page tables pour ce segment sont conservées dans l’objet sous-jacent, et ne sont plus détruites lors d’un fork(). En outre, les page tables concernées ne sont plus dupliquées dans les pmap de chaque processus, mais sont partagées.

Cette optimisation permet d’améliorer les performances dans ce genre de conditions, mais aussi au lancement d’applications X par exemple, et de réduire la pression sur le cache des processeurs. Pour en savoir plus, voir le message de Matt Dillon à ce sujet

Autres optimisations SMP

Outre le travail sur l’ordonnanceur, de nombreux goulots d’étranglement ont été supprimés dans diverses parties du noyau, comme les sockets unix, ou les sémaphores POSIX.

Tout ce travail a conduit à une impressionnante amélioration du passage à l’échelle dans divers domaines. Cette amélioration est particulièrement visible dans le cas de pgbench, puisque c’est ce test de performance qui a été surtout utilisé pour identifier les goulots cette fois-ci, mais elle touche beaucoup d’usages. Ce PDF illustre les améliorations obtenues et donne à titre indicatif les chiffres obtenus sur d’autres BSD ou sur Linux avec la même machine : entre DragonFly 3.0 et 3.2, il s’agit d’une amélioration de 500% dans le meilleur des cas.

Dans ce graphique, les meilleures performances sont les nombres des ordonnées les plus élevés.

Pile USB

Markus Pfeiffer a porté la nouvelle pile USB introduite dans FreeBSD 8, après 5 ans de développement. Cette nouvelle pile permet notamment de gérer la norme USB3 et devrait améliorer grandement la gestion de l’USB, ainsi que les performances. Cette pile n’est toutefois pas compilée par défaut, car l’import est récent et n’a pas encore été largement testé.

Systèmes de fichiers

puffs

Un port de PUFFS depuis NetBSD et FreeBSD, issu du projet de Nick Prokharau pour le GSoC 2011 a été inclus. PUFFS est un mécanisme permettant d’implémenter des systèmes de fichiers en espace utilisateur. Il est composé de plusieurs parties :

• Le sous-système puffs, dans le noyau, qui s’intègre à la couche VFS, et qui exporte une interface utilisateur via un fichier dans /dev.
• une bibliothèque libpuffs qui permet de communiquer simplement avec la partie noyau et qui fournit un ensemble d’utilitaires pour simplifier la création de systèmes de fichiers.
• une bibliothèque librefuse qui fournit une couche de compatibilité avec le système Filesystem_in_Userspace utilisé par Linux.

vquota

Le système de gestion des quotas a été modifié. vquota(8) est un sous-système permettant de définir des quotas de manière indépendante du système de fichiers sous-jacent, en se basant sur la couche VFS. Il faut noter toutefois que ce problème soulève des questions difficiles à résoudre : combien de fois par exemple doit-on compter les hardlinks d’un même fichier ? Ou, pire, le système de fichiers Hammer conserve l’historique des transactions et, donc, des contenus pour une durée déterminée. Un fichier de 20 Ko, modifié souvent, peut en réalité prendre plusieurs Mo sur le disque.

tmpfs

tmpf(5) est un système de fichiers résidant dans la mémoire virtuelle. Il a profité de diverses corrections de bugs et améliorations. Par exemple, les répertoires ont désormais une structure d’arbre rouge/noir et non de liste, ce qui accélère les opérations de recherche. En outre, les systèmes de fichiers tmpfs sont désormais accessibles par NFS.

pilotes et réseau

Côté réseau, on notera l’ajout d’un nouveau pilote pour les cartes réseau Intel 10Gb (ixgbe(4)) ainsi que la mise à jour des pilotes pour les cartes Broadcom (bge(4), bnx(4)). Également notable, un gros travail sur TSO (TCP Segmentation Offload) qui touche les pilotes em(4), emx(4), bce(4), bge(4), bnx(4), igb(4) et jme(4) et sur la conformité et l’implémentation des standards :

• RFC3390 (Increasing TCP’s Initial Window),
• RFC6298 (Computing TCP’s Retransmission Timer),
• RFC6633 (Deprecation of ICMP Source Quench Messages),
• RFC4015 (The Eifel Response Algorithm for TCP),
• RFC6675 (A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP)
• et RFC4653 (Improving the Robustness of TCP to Non-Congestion Events).

Diverses autres améliorations ont eu lieu, avec près de 400 commits.

Côté RAID matériel, on compte deux nouveaux pilotes : hpt27xx(4) pour les cartes à base de HighPoint RocketRAID 27xx et hptrr(4) pour toute une série de modèles de la même marque. Une grande partie des autres pilotes de contrôleurs RAID ont été mis à jour.

Des pilotes pour gérer les watchdog des chipsets AMD et Intel ont été importés de FreeBSD, ichwd(4) et amdsbwd(4), et l’implémentation ACPI a été mise à jour.

Espace utilisateur

GCC 4.7

DragonFly contient deux compilateurs dans sa base. Sous DragonFly 3.0, il s’agissait de GCC 4.4 comme compilateur par défaut et de GCC 4.1 comme second compilateur. John Marino s’est attelé à la lourde tâche d’intégration de GCC 4.7, qui est désormais le compilateur secondaire et qui permet de compiler un système fonctionnel.

Il faut noter qu’il est possible de compiler le système avec clang, fourni comme paquet via pkgsrc. L’opinion actuelle est que GCC 4.7 risque de rester dans la base pour un moment, même si clang pourrait y être introduit, notamment car il est le dernier GCC qui ne nécessite pas C++.

Éditeur de liens dynamiques

L’éditeur de liens dynamiques permet de retarder l’édition des liens à l’exécution et, donc, d’utiliser des bibliothèques partagées. RTLD, l’éditeur de liens dynamiques de DragonFly est le même que celui de FreeBSD, les deux projets contribuant à son développement. Outre diverses améliorations, il gère désormais l’extension GNU DT_GNU_HASH pour le format ELF, qui permet de réduire le temps de recherche des symboles. Le système de base tire parti de cette fonctionnalité. Dans la pratique, ces changements permettent de réduire de 50% le temps de chargement de certains binaires.

Divers

Pour ceux qui se demandent s’il y a des interactions entre les BSD, dhclient(8) a été mis à jour depuis OpenBSD, ftp(1) et libedit depuis NetBSD, cut(1) et sh(1) depuis FreeBSD. Il existe également des projets communs tels que libarchive qui a pour l’occasion été mise à jour en version 3.0.4.

La commande mount essaie désormais de détecter automatiquement le type de système de fichiers.

Paquets

DragonFly fournit des paquets binaires basés sur pkgsrc, le système de paquet issu de NetBSD. Les paquets binaires peuvent être simplement gérés par un gestionnaire de paquets (pkg_radd, ou même pkgin), comme sous les distributions GNU/Linux. Avec la version 3.2, c’est la branche pkgsrc-2012Q3 qu’on peut installer par défaut. Rappelons que les paquets ne font pas à proprement parler partie de l’OS et qu’il s’agit de logiciels tiers. Pkgsrc donne accès à plus de 13000 paquets.

Qualité du code

Malgré son peu de ressources humaines, les développeurs de DragonFlyBSD apportent un grand soin à la qualité du code et de la documentation. On remarquera en particulier le travail de Sascha Wildner qui se consacre presque exclusivement à cette tâche. Entre la version 3.0 et 3.2, on a 25254 commits, dont 1788 concernent les pages de man et 347 les tests. Avec les corrections de style, de coquilles, les suppressions de code mort, la mise à jour de code utilisant d’anciennes API, on peut considérer qu’environ 15% à 25% de l’activité concerne l’amélioration de la qualité.

Projets

Hammer2

En mai 2011, Matt a publié une première spécification du système de fichiers hammer2. Il s’agit d’une évolution majeure de hammerfs, proposant de véritables fonctionnalités réseau. Quelques mois après, la branche hammer2 sur le dépôt git, permettait d’entrer dans le vif du sujet.

La première tâche à laquelle Matt s’est attelé concerne les briques de base de la partie réseau. Il fait état de leur avancement dans un long message début août. Actuellement, l’implémentation permet aux machines de se connecter entre elles de façon chiffrée et d’échanger des messages transactionnels. Un protocole de type spanning tree protocol permet la diffusion de l’information au niveau du cluster. L’idée est de pouvoir utiliser un seul système de fichiers sur plusieurs machines, sans avoir à se soucier manuellement de la topologie du réseau. Les différentes instances communiquent entre elles, permettant une mise à jour des pfs (les "volumes" de hammer) en ligne ou une resynchronisation à la connexion.

Hammer2 devant permettre une grande souplesse dans les choix topologiques (toutes les combinaisons possibles de nœuds maîtres, esclaves, cache et client), l’implémentation de ces briques de base est essentielle et laborieuse. Cela dit, Matt pense bientôt voir le bout du tunnel et commencer la partie amusante (sic), c’est-à-dire l’implémentation de fonctionnalités de haut niveau : haute disponibilité, réplication, répartition…

Le système d’échange de messages a par ailleurs été généralisé et poussé dans master, car il devrait trouver des applications hors de hammerfs, comme l’exposition de périphériques sur le réseau.

bmake

Comme c’est le cas pour son cousin FreeBSD, DragonFlyBSD est en train de changer d’implémentation de make. Le vénérable pmake, peu maintenu, sera remplacé par bmake issu de NetBSD.

inotify

Vishesh Yadav a travaillé cet été dans le cadre du GSoC à une implémentation de l’interface inotify sous DragonFlyBSD. Il semble que son code doive être commité bientôt. L’intérêt d’inotify, par rapport à kqueue, est d’éviter d’avoir à maintenir un descripteur de fichier par fichier surveillé. L’API proposée par Linux semblant stable et efficace, elle sera utilisable en plus de kqueue, améliorant la compatibilité entre les deux OS.

Desktop

Il y a eu courant juillet un long fil sur l’utilisation de DragonFlyBSD comme Desktop. Stéphane Russell y raconte son expérience qui n’est, selon son expression, pas si mauvaise. À noter qu’un certain nombre de commits sur les pilotes de carte audio, le précédent travail sur KMS et la nouvelle pile USB devraient améliorer les choses. XFCE semble être l’environnement de bureau le plus fonctionnel.

Lire les commentaires

Cet article est repris du site http://linuxfr.org/news/dragonflybs...