DragonFly BSD 3.6

La version 3.6 du système d'exploitation DragonFly BSD est désormais disponible, apportant notamment une amélioration considérable des performances pour les machines SMP. Les détails concernant cette version se trouvent dans la suite de la dépêche.

Sommaire

• Noyau
  • Réseau
  • Vkernel
  • Améliorations SMP
  • Vidéo
    • liens
  • Mémoire
  • Hammer2
  • Divers
  • USB
• Espace utilisateur
  • Synchronisation de code avec divers BSD
    • Import de mdocml
    • Synchronisation de locale/libiconv avec FreeBSD
    • Ajout de la commande poweroff
    • Mise à jour de libedit
  • Mise à jour de logiciels tiers
    • Mise à jour de less
    • Mise à jour de gdb et kgdb
  • Améliorations de systat
  • Améliorations de df
  • Amélioration de killall
  • Amélioration de dmesg
• Dports et pkgng
• GSOC
  • Checkpoints pour les vkernel
  • Implémentation de System V IPC en espace utilisateur
• Notes de mise à jour

La liste des changements dans la suite de la dépêche n'est pas exhaustive mais essaye de donner un bon aperçu des développements qui ont eu lieu durant le dernier cycle. Pour la liste complète, allez voir les commits des tags 3.6.0rc et 3.6.0.

Noyau

Réseau

DragonFly 3.6 bénéficie d'un gros travail de la part de Sepherosa Ziehau sur les pilotes Ethernet pour le support des interruptions MSI-X et des queues multiples. Le simple fait de permettre au pilote mxge pour les adaptateurs Ethernet 10 Gigabit Myricom d'en bénéficier a fait augmenter ses performances en transmission de 150Mbps.

Les performances des appels non bloquants à connect() pour les connections tcp ont été améliorées. Le gain mesuré est de 16%.

SO_REUSPORT fait maintenant de la répartition de charge comme sous Linux et permet de distribuer la réception de données sur plusieurs sockets pouvant tourner chacun sur des threads différents. Nginx a été patché dans dports pour prendre en compte ce mécanisme et les premières mesures font apparaître une amélioration des performances de 33%.

Autres changements dans les pilotes Ethernet:

• ajout du support des cartes Ethernet 10Gb/s Emulex OneConnect ;
• mise à jour des pilotes Ethernet igb(4) et em(4) ;
• activation de la fonctionnalité TSO pour les chipsets en PCI-Express gérés par le pilote em(4) ;
• ajout du support de nombreux nouveaux chipsets realteks dans le pilote re(4).

On devrait aussi remarquer une amélioration de la stabilité et des performances de la table de routage sous des charges extrêmement élevées.

Vkernel

DragonFly possède un système de noyau virtuel nommé vkernel. Dans l'idée, le concept est plus ou moins similaire au UML (User Mode Linux) de Linux. Il s'agit donc d'un mécanisme de virtualisation permettant de faire tourner un noyau DragonFly en espace utilisateur. Ce système est très utile pour le développement du noyau puisqu'il permet de ne pas avoir à redémarrer la machine pour tester les changements apportés. Si vous voulez en savoir plus, je vous conseille de lire cet article qui est excellent bien que relativement daté.

Les vkernels bénéficient maintenant d'une accélération matérielle sur les processeurs Intel comportant la technologie de virtualisation EPT (Extended Page Tables). Ce travail a été principalement réalisé par Mihai Carabas dans le cadre d'un projet Google Summer of Code. Mihai avait déjà implémenté la détection des topologies coeurs/socket/threads pour les machines NUMA et SMP modernes l'an dernier. Des informations plus détaillées sont visibles dans le message de commit Vkernel/VMM.

DIRFS a été ajouté. Il s'agit d'un pseudo-système de fichiers spécifique aux vkernels qui permet de monter les dossiers de l'hôte directement dans le vkernel.

Améliorations SMP

L'utilisation de monster (un serveur AMD Opteron avec 48 cœurs) pour la compilation des paquets a permis d'améliorer la situation concernant les contentions pour les machines SMP. Pour citer Matt Dillon :

The jist of this work is that there is no longer virtually any
contention for most process-related activities, including heavy use
of fork and fork/exec in 'make', '/bin/sh', and other utilities.
Anything which forks and/or execs a lot (scripts, bulk builds, service
daemons, etc) will now run as close to optimally as it is possible to
run on a multi-core box.

In particular with the last change to the namecache code, our bulk
ports builds look pretty insane on monster (our 48-core opteron box).
Now during a bulk dports build, the load can pop up to 300 with concurrent
compiles and of that 300 there will be 295 non-contending "R"un state
processes and only 5 contending "D" state processes. And it all happens
with virtually NO IPI traffic between cpus.

I consider this a fairly major milestone for the project. We aren't
finished, but this is a major leap in our ability to fully utilize the
resources on larger multi-core systems.

En voici une traduction approximative :

Ces modifications suppriment presque tous les points de contention pour les opérations liées aux processus, notamment l'usage important de fork et de fork/exec dans 'make' et '/bin/sh', ainsi que dans d'autres outils.
Tout ce qui utilise un grand nombre de forks et/ou d'execs (les scripts, la compilation d'un grand nombre de paquets, les daemons, etc) s'exécute maintenant de la manière la plus optimale possible sur une machine à plusieurs cœurs.

En particulier, grâce au dernier changement dans le code du cache des noms de fichiers, la compilation de l'ensemble des ports est vraiment impressionnante sur monster (notre machine 48 cœurs à base de processeurs opteron). Désormais, durant une compilation, la charge peut culminer à 300 avec des compilations concurrentes, et parmi ces 300 processus, il y a 295 processus à l'état "R" (running) sans contention, et simplement 5 processus bloqués sur un point de contention à l'état "D". Et tout cela avec quasiment aucun traffic d'IPI entre les cpus.

Je considère cela comme une étape assez importante du projet. Nous n'avons pas fini, mais c'est un progrès majeur vers notre objectif d'utiliser entièrement les ressources des plus gros systèmes multi-cœurs.

Pour les détails, référez-vous aux messages de Matt Dillon sur la liste de diffusion ici et là.

Vidéo

Le sous-système drm du noyau a été mis à jour et comporte maintenant des pilotes i915/kms et radeon/kms ainsi que leurs gestionnaires mémoire associés. Il est désormais possible d'utiliser directement une grande partie des chipsets graphiques intégrés Intel avec Xorg à condition que l'on utilise un système DragonFly 64-bit. Ceci a été rendu en grande partie possible par le travail réalisé par les dévelopeurs FreeBSD sur ces pilotes. Le code a été également amélioré grâce à l'import de routines OpenBSD et une synchronisation partielle avec l'implémentation drm de Linux 3.8.

Le support radeon/kms est considéré encore trop jeune pour être activé par défaut dans les pilotes Xorg. Il faut installer à la main une version plus récente de xf86-video-ati pour l'utiliser.

liens

i915 drm avec kms :

• http://lists.dragonflybsd.org/pipermail/users/2013-July/053643.html ;
• http://lists.dragonflybsd.org/pipermail/commits/2013-September/198064.html ;
• http://lists.dragonflybsd.org/pipermail/users/2013-September/090138.html ;
• http://lists.dragonflybsd.org/pipermail/commits/2013-September/198076.html.

Import du gestionnaire de mémoire ttm : http://lists.dragonflybsd.org/pipermail/commits/2013-August/130607.html.

Import du pilote radeon KMS depuis FreeBSD : http://lists.dragonflybsd.org/pipermail/commits/2013-October/198282.html.

Mémoire

Quelques changements ont eu lieu dans la collecte des statistiques d'utilisation de la mémoire. De plus, les erreurs ECC remontées par le contrôleur mémoire des processeurs Xeon E3 Ivy-Bridge et Haswell sont désormais gérées par le noyau.

Hammer2

Le développement du nouveau système de fichier Hammer2 se poursuit, essentiellement effectué par Matt Dillon. Le code de dé-allocation des blocs inutilisés n'est toujours pas présent, ce qui empêche toute utilisation réelle du FS. Hammer2 continue cependant à être stabilisé et depuis le mois de novembre, il peut survivre à la compilation de l'ensemble des ports avec poudrière.

Lors du Google Summer Of Code, la prise en charge de la compression à la volée des fichiers a été ajoutée. Les algorithmes ZLIB et LZ4 sont gérés, et la prise en charge de la compression peut être configurée par PFS (pseudo filesystem). Quelques tests ont été conduits et ont permis de mettre en évidence que la compression a un coût acceptable, et parfois peut augmenter les perfomances, non seulement en lecture mais aussi en écriture.

Hammer2 peut maintenant être utilisé pour le boot, ce que ne permettait pas Hammer.

Divers

Si vous utilisez DragonFlyBSD sur une machine à processeur Cyrix, attention : certaines options spécifiques à ces puces ont été retirées. On notera aussi la présence d'un nouveau timer, plus de précisions ici et là.

Le code flush/sync du système de fichiers a été amélioré, encore une fois pour améliorer le passage à l'échelle. Au lieu de parcourir la liste de tous les vnodes, la structure de données représentant un "fichier" dans le noyau pour trouver ceux qui nécessitent un flush vers le disque, le code maintient une liste des vnodes dans l'état "dirty", c'est-à-dire ceux qui doivent être synchronisés avec le disque. Sachant que le nombre de vnodes peut atteindre plusieurs millions sur un gros système, cette modification améliore grandement les performances de sync.

USB

La nouvelle pile USB importée de FreeBSD continue à recevoir des améliorations. Toutefois, elle n'est toujours pas compilée par défaut car l'utilisation d'USB 3 n'est pas encore entièrement stabilisée.

Espace utilisateur

Synchronisation de code avec divers BSD

Import de mdocml

mdocml a été importé. Il s'agit d'une alternative à groff pour l'affichage des pages de manuel au format mdoc. Une fois que la majorité des erreurs de rendu auront été corrigées, il est prévu de remplacer GNU man(1) par le nouvel outil man(1) qui utilise mdocml au lieu de groff. À noter que les changements sur man apportés par DragonFly ont rapidement été adoptés par l'équipe de NetBSD. D'autres changements ont également été importés en retour dans OpenBSD. mdocml a également été intégré dans les sources de FreeBSD 10. Il est intéressant de voir que cet outil se trouve dans tous les principaux systèmes *BSD et que leurs équipes de développement collaborent en allant dans la même direction.

Synchronisation de locale/libiconv avec FreeBSD

Le support des locales dans la libc et de libiconv a été grandement amélioré. Le code actuel était un mélange de code venant de NetBSD et de code venant de FreeBSD. Une grande partie de la libc a été synchronisée avec FreeBSD, et le support des locales est désormais basé sur le code de FreeBSD. Par la même occasion, le support des wide chars a été amélioré. Libiconv fournit une interface à jour, ce qui permet d'activer un meilleur support de la localisation dans les logiciels tiers fournis par dports.

Ajout de la commande poweroff

La commande poweroff(8), qui n'était pas présente dans DragonFly mais présente depuis près de trois ans chez FreeBSD et bien connue dans le monde Linux, a été adoptée depuis les sources de FreeBSD. Il s'agit d'un équivalent à shutdown -p now ou halt -p.

Mise à jour de libedit

Libedit, une bibliothèque de gestion d’édition d'une ligne de commande similaire à GNU readline sous licence BSD a été mise à jour en version 2012-12-13.

Mise à jour de logiciels tiers

Mise à jour de less

less a été mis à jour vers la version 458, apportant son lot de corrections et de nouvelles fonctionnalités par rapport à la version 444 anciennement présente.

Mise à jour de gdb et kgdb

La version de gdb et kgdb inclue dans base a été mise à jour en version 7.6.1. En particulier, cela améliore un peu le débogage de vkernel.

Améliorations de systat

systat a vu l'ajout des options -netbw et -pftop.

Améliorations de df

L'outil df, bien connu des administrateurs systèmes, a vu l'ajout de l'option -T qui permet d'afficher les types de systèmes de fichiers associés aux partitions listées. De plus, df affiche maintenant les inodes de manière "human-readable" lorsque les options -h et -i sont utilisées conjointement.

Amélioration de killall

killall bénéficie désormais de l'option -T. Cette option tue tous les processus générés par le TTY appelant à l'exception du processus parent de killall. Ceci permet donc de tuer tous les processus du TTY courant sans tuer le shell courant.

Amélioration de dmesg

L'option -f permet désormais de récupérer les messages du noyau en continu

Dports et pkgng

Les dports sont maintenant compilés avec gcc 4.7 au lieu de gcc 4.4. La prochaine version de DragonFly abandonnera vraisemblablement ce dernier au profit de clang puisqu'à partir de la version 10.0 de FreeBSD les ports seront compilés avec, les dports étant issus de ces derniers.

Pour rappel, DragonFly 3.4 a introduit pkgng comme alternative à pkgsrc. Suite à l'enthousiasme des utilisateurs envers pkgng (en mai dernier, 98.55% des téléchargements de paquets concernaient les versions pkgng/dports) et les excellents résultats obtenus via l'import des ports FreeBSD, ce dernier est désormais officiellement adopté au dépend de pkgsrc, l'équipe n'ayant ni les ressources humaines ni matérielles pour maintenir les deux en parallèle. Par conséquent, si vous utilisez encore pkgsrc, il faudra obligatoirement migrer vers pkgng après une mise à jour depuis la 3.4.

On peut remarquer au passage que DragonFly a eu des dépôts de paquets pkgng officiels bien avant FreeBSD. Les dépôts de FreeBSD ne sont arrivés que fin octobre 2013 (voir dépêche FreeBSD Miroirs pkgng disponibles !) alors que ceux de DragonFly étaient déjà présents pour la version 3.4, sortie en avril de cette même année.

La migration vers pkgng rend facilement installable un nombre plus importants de paquets. En effet, là où pkgsrc proposait l'installation d'environ 10 000 paquets, pkgng en propose désormais plus de 20 000.
À noter que, à la manière de ce qui est fait chez FreeBSD, les paquets sont également installables via les dports par le biais d'une compilation manuelle. Cela permet de choisir des options différentes de celles par défaut pour les paquets et l'installation par ce biais permet naturellement de les gérer via pkgng une fois installés.

Si vous n'avez pas encore les dports, il existe trois moyens simples pour les obtenir:
cd /usr
1) make dports-create: cela a pour effet de cloner l'entier du dépôt dports depuis Github dans /usr/dports.
2) make dports-create-shallow: le dépôt est cloné sans l'historique. Le dépôt peut néanmoins être mis à jour depuis /usr/dports (cd /usr/dports && git pull).
3) make dports-download: télécharge un tarball du dépôt et le décompresse dans /usr/dports.

Si vous rencontrez un problèmes avec un dport ou si vous souhaitez fournir un patch (pour, par exemple, corriger un port qui compile sous FreeBSD mais pas sous DragonFly ;) ), il faudra passer par le tracker de Github.

GSOC

D'autres projets ont été développés lors du google summer of code, mais n'ont pas encore été importés dans la branche principale et sont en cours de stabilisation.

Checkpoints pour les vkernel

DragonFly supporte un système de checkpoint, qui permet de sérialiser l'état d'un processus sur le disque (à l'aide d'un core dump) et de le restaurer par la suite. Pawel Dziepak a mis à jour cette fonctionnalité pour qu'elle fonctionne correctement avec les applications à plusieurs threads, puis pour qu'elle fonctionne avec les vkernels.

Implémentation de System V IPC en espace utilisateur

Grigore Larisa a créé un démon fournissant l'API sysvipc en espace utilisateur pouvant remplacer l'implémentation du noyau. Elle a posté des tests de performances réalisés avec pgbenchs, qui semblent assez prometteurs.

Notes de mise à jour

La procédure de mise à jour depuis la version 3.4 diffère légèrement de la procédure habituelle. En effet, un redémarrage de la machine est nécessaire avant d'appliquer un make upgrade.
Voici donc les commandes à appliquer pour la mise à jour (avec les droits root):

cd /usr/src
git fetch origin
git branch DragonFly_RELEASE_3_6 origin/DragonFly_RELEASE_3_6
git checkout DragonFly_RELEASE_3_6
make buildworld && make buildkernel && make installkernel && make installworld && reboot
make upgrade

Le changement du numéro d'ABI demande une réinstallation de tous les paquets binaires (dports). Assurez-vous donc d'utiliser pkg clean afin de purger les anciens paquets du cache avant de procéder à leur mise à jour avec les commandes pkg update et pkg upgrade -f

Aller plus loin

• Site officiel du projet (308 clics)
• Notes de version 3.6 (43 clics)
• Dépôt des paquets tiers (Dports) (30 clics)