URL: https://linuxfr.org/news/dragonflybsd-3-2-la-libellule-s-envole-toujours-plus-haut Title: DragonFlyBSD 3.2, la libellule s’envole toujours plus haut Authors: Enj0lras esdeem, Joris Dedieu, galactikboulay, baud123, Davy Defaud, Benoît Sibaud, NeoX, Nÿco, claudex et bastien Date: 2012年10月15日T20:10:45+02:00 License: CC By-SA Tags: dragonflybsd, bsd et postgresql Score: 59 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._ ---- [Notes de version de DragonFly 3.2](http://www.dragonflybsd.org/release32/) [Site officiel du projet](http://www.dragonflybsd.org/) [Page de téléchargement](http://www.dragonflybsd.org/download/) [L’annonce de la disponibilité des images](http://lists.dragonflybsd.org/pipermail/users/2012-November/017653.html) ---- # 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](http://lists.dragonflybsd.org/pipermail/kernel/2012-August/015478.html), 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](http://leaf.dragonflybsd.org/~mihaic/openssl_smt_bench.out) * 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](http://www.postgresql.org/docs/9.1/static/pgbench.html) 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](http://lists.dragonflybsd.org/pipermail/users/2012-September/017490.html), > 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. 1. 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. 1. 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](http://www.freebsd.org/doc/en/articles/vm-design/index.html) 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](http://lists.dragonflybsd.org/pipermail/kernel/2012-September/015514.html) ### 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](http://lists.dragonflybsd.org/pipermail/commits/2012-September/031436.html) [unix](http://lists.dragonflybsd.org/pipermail/commits/2012-September/031435.html), ou les [sémaphores POSIX](http://lists.dragonflybsd.org/pipermail/commits/2012-September/031439.html). 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](http://lists.dragonflybsd.org/pipermail/users/attachments/20121010/7996ff88/attachment-0002.pdf) : entre DragonFly 3.0 et 3.2, il s'agit d'une amélioration de 500% dans le meilleur des cas. ![Augmentation des performances](http://rmdir.fr/plop.jpg) 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](http://www.google-melange.com/gsoc/project/google/gsoc2011/nickprok/12001) a été inclus. [PUFFS](http://www.netbsd.org/docs/puffs/index.html) 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](http://leaf.dragonflybsd.org/cgi/web-man?command=puffs§ion=3) 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](http://leaf.dragonflybsd.org/cgi/web-man?command=refuse§ion=3) qui fournit une couche de compatibilité avec le système [Filesystem_in_Userspace](http://fr.wikipedia.org/wiki/Filesystem_in_Userspace "Définition Wikipédia") utilisé par Linux. #### vquota Le système de gestion des quotas a été modifié. [vquota(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=vquota§ion=ANY) 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)](http://leaf.dragonflybsd.org/cgi/web-man?command=tmpfs§ion=ANY) 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)](http://leaf.dragonflybsd.org/cgi/web-man?command=ixgbe§ion=ANY)) 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]( http://www.ietf.org/rfc/rfc3390.txt) (Increasing TCP's Initial Window), * [RFC6298](http://www.ietf.org/rfc/rfc6298.txt) (Computing TCP's Retransmission Timer), * [RFC6633](http://www.ietf.org/rfc/rfc6633.txt) (Deprecation of ICMP Source Quench Messages), * [RFC4015](http://www.ietf.org/rfc/rfc4015.txt) (The Eifel Response Algorithm for TCP), * [RFC6675](http://www.ietf.org/rfc/rfc6675.txt) (A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP) * et [RFC4653](http://www.ietf.org/rfc/rfc4653.txt) (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)](http://leaf.dragonflybsd.org/cgi/web-man?command=hpt27xx§ion=ANY) pour les cartes à base de HighPoint RocketRAID 27xx et [hptrr(4)](http://leaf.dragonflybsd.org/cgi/web-man?command=hptrr§ion=ANY) 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)](http://leaf.dragonflybsd.org/cgi/web-man?command=ichwd§ion=4) et [amdsbwd(4)](http://leaf.dragonflybsd.org/cgi/web-man?command=amdsbwd§ion=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](http://libarchive.github.com/) 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](http://www.netbsd.org/docs/software/packages.html). Les paquets binaires peuvent être simplement gérés par un gestionnaire de paquets (pkg_radd, ou même [pkgin](http://pkgin.net/)), 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](http://gitweb.dragonflybsd.org/dragonfly.git?a=search&st=author&s=Sascha+Wildner) 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](http://apollo.backplane.com/DFlyMisc/hammer2.txt). Il s'agit d'une évolution majeure de [hammerfs](http://fr.wikipedia.org/wiki/hammerfs "Définition Wikipédia"), 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](http://lists.dragonflybsd.org/pipermail/users/2012-August/017332.html) 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](http://fr.wikipedia.org/wiki/spanning tree protocol "Définition Wikipédia") 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]( http://lists.dragonflybsd.org/pipermail/commits/2012-October/031929.html), 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](http://wiki.freebsd.org/build), DragonFlyBSD est en train de changer d'implémentation de make. Le vénérable pmake, peu maintenu, sera remplacé par [bmake](http://ftp.netbsd.org/pub/NetBSD/misc/sjg/) issu de NetBSD. ## inotify Vishesh Yadav [a travaillé cet été](http://www.google-melange.com/gsoc/project/google/gsoc2012/vishesh/37002) dans le cadre du GSoC à une implémentation de l'interface [inotify](http://fr.wikipedia.org/wiki/inotify "Définition Wikipédia") sous DragonFlyBSD. Il semble que son code doive être commité [bientôt](http://www.shiningsilence.com/dbsdlog/2012/08/24/10245.html). 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](http://leaf.dragonflybsd.org/mailarchive/users/2012-07/msg00079.html) 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. ![dargonfly xfce](http://rmdir.fr/deagonflygui.png)

AltStyle によって変換されたページ (->オリジナル) /