points de vue

les déambulations d'un codeur

Aller au contenu | Aller au menu | Aller à la recherche

Un petit voyage dans DragonFly BSD

DragonFly BSD est le dernier rejeton de la famille des Unix BSD libres. Il est issu du désaccord de Matthew Dillon sur les choix d’architecture SMP de FreeBSD 5. Créé en 2003 à partir de FreeBSD 4.8 pour initialement proposer une autre implémentation du multi-threading (multiflot en français), plus originale, il devient l’opportunité, pour l’équipe de DragonFly BSD, d’emprunter des directions différentes, voir innovantes, de celles des autres systèmes Unix.

Dans cette partie, je vais vous présenter DragonFly BSD avant de vous proposer, dans une seconde partie, son installation et sa configuration.

Initialement, les noyaux des systèmes libre de type Unix (FreeBSD, NetBSD, OpenBSD et Linux) reposaient tous sur une architecture multitâches simple dans laquelle les ressources du noyau étaient protégées, dans un environnement SMP, par un verrou global (Giant Lock). Avec l’avènement des architectures matérielles multi-cœur et le développement croissant d’applications fortement multitflots, cette approche devint un véritable problème, conduisant à des goulet d’étranglement et à un effondrement sous forte charge. Les équipes des différents systèmes se mirent alors, au début du 21e siècle, à travailler sur une architecture SMP et multi-threading différente dans laquelle le verrou global est remplacé par des primitives de synchronisation plus fines, les mutex, et le support multitâche laisse sa place à un modèle de threads noyaux/utilisateurs combinés. Pour FreeBSD 5, l’équipe de développement choisit une approche multi-threading m:n dans laquelle à n threads noyaux sont associés m noyaux utilisateurs (avec n < m). C’est un choix risqué car relativement complexe à mettre en œuvre au point qu’avec FreeBSD 6 commença un retour en arrière en adoptant aussi le modèle 1:1, plus simple, pour devenir celui par défaut dans FreeBSD 7 (le modèle m:n est enlevé dès FreeBSD 8).

Mattew Dillon, un des développeur de FreeBSD, était déjà persuadé que les choix techniques adoptés en matière de SMP et de multi-threading dans FreeBSD 5 n’étaient pas les bons. Il les jugeait trop complexe et, par ce fait, sujet à de performances trop pauvres et à une maintenance trop difficile. Parce que non écouté et rebuté, il décida alors de fonder sa propre solution, basé sur ses idées, à partir de FreeBSD 4.8. C’est ainsi qu’est né DragonFly BSD qui, aujourd’hui, a significativement divergé de FreeBSD.

Le noyau de DragonFly BSD est conçu autour d’un système de bus à messages pouvant agir aussi bien en synchrone qu’en asynchrone. La communication entre les différents sous-systèmes se font par le biais de ce bus et même les appels systèmes sont encapsulés par des messages. Cette approche permet non seulement une meilleur protection mémoire des sous-systèmes mais aussi de pouvoir migrer certaines parties du noyau dans l’espace utilisateur dans lequel il est plus facile de coder et de déboguer, voir même de monter en charge. L’architecture SMP et multi-threading du noyau repose sur un modèle 1:1 sans-verrous à base de jetons de sérialisation (serializing tokens) pour l’accès concurrent aux ressources. Dans cette architecture, les threads sont attribués par processeur ou cœur par un sous-système d’ordonnancement à deux étages : un ordonnanceur dans l’espace noyau qui a pour tâche d’ordonnancer l’ensemble des threads par CPU et un ordonnanceur dans l’espace utilisateur qui sélectionne un thread à la fois pour chaque CPU disponible et qui utilise l’ordonnanceur du noyau. La commutation entre threads ne se fait pas de manière préemptive, comme avec les autres systèmes, mais par le biais de messages IPI (Inter-Processor Interrupt). Ces choix ne sont pas encore aujourd’hui totalement réalisés mais permettent déjà d’atteindre une montée en charge bien supérieure aux autres BSD et proche de celle d’un GNU/Linux, d’autant plus que des améliorations, empruntés du monde Linux, ont été introduites dans le noyau.

Les évolutions de DragonFly BSD ne s’arrêtent pas pour autant au multitâche. Les développeurs ont décidé aussi d’emprunter d’autres directions et de profiter de DragonFly BSD pour expérimenter leurs idées. C’est ainsi qu’un mécanisme de virtualisation, vkernel, a vu le jour avec la version 1.8, permettant de faire tourner un noyau dans l’espace utilisateur et ceci de manière complètement isolée d’avec le reste du système. Avec la version 1.12, Matt introduit de façon expérimentale un nouveau système de fichier à haute disponibilité à répartition avec les mêmes caractéristiques que ZFS : Hammer. Il est aujourd’hui proposé par défaut à l’installation et Matt développe une nouvelle version majeur de celui-ci, Hammer2. Avec swapcache, DragonFly BSD utilise le swap sur disque SSD pour mettre en cache des données et méta-données, conduisant ainsi à de meilleurs performances. Et ainsi de suite. D’autres évolutions existent et continuent d’améliorer DragonFly BSD et d’en faire un Unix BSD à part. J’espère que cet article vous aura convaincu de la particularité, du point de vue technique, de DragonFly BSD et qu’il vous aura donné envie de l’essayer.

Miguel Moquillon

Auteur: Miguel Moquillon

Restez au courant de l'actualité et abonnez-vous au Flux RSS de cette catégorie

Commentaires (0)

Soyez le premier à réagir sur cet article

Ajouter un commentaire Fil des commentaires de ce billet

no attachment



À voir également

Le SnowCamp 2017

Le SnowCamp a été renouvelé cette année et a eu lieu du 8 au 11 février avec cette même formule qui a fait le succès de la première édition : une journée d’université le merdredi au World Trade Center, deux jours de conférences le jeudi et vendredi à l’Université des Alpes et une journée d‘“unconference” sur les pistes de ski de Chamrousse le samedi.

Lire la suite

Sticker_SnowCamp_2016_-_CommitStrip.png

Le SnowCamp 2016

Je vous propose un petit compte rendu du SnowCamp 2016 qui s’est déroulé du 20 au 23 janvier à Grenoble et ceci en toute … subjectivité étant un des organisateurs de cet événement. Mais d’abord, qu’est-ce que le SnowCamp ? C’est une manifestation faite par les codeurs à destination des codeurs et qui profite du pôle technologique et d’innovation qu’est Grenoble pour ouvrir ses portes aux thésards et aux chercheurs afin qu’ils nous fassent profiter de leur travaux.

Lire la suite