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 en vue de supprimer le Giant Lock. 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.
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. 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 goulets d’étranglement et à un effondrement du système sous forte charge. Les équipes des différents systèmes d’exploitation 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 ambitieux, mais risqué car relativement complexe à mettre en œuvre, tant et si bien qu’avec FreeBSD 6 commença un retour en arrière en adoptant 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). Le modèle 1:1 a été choisi dès le début par l’équipe de développement du noyau Linux.
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 à des performances trop pauvres et à une maintenance trop difficile. Parce que non écouté et rebuté, il décida alors de fonder sa propre solution, basée 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 comme sous Linux mais sans-verrous, et donc à base de jetons de sérialisation 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 de charge 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.