Sortie de DragonFlyBSD 1.4

Posté par  (site web personnel) . Modéré par Amaury.
Étiquettes :
0
10
jan.
2006
FreeBSD
Le projet DragonFlyBSD est issu d'une divergence entre les développeurs de FreeBSD et Matt Dillon qui était un contributeur régulier. Celui-ci pensait que le chemin emprunté par la série des FreeBSD 5.x n'était pas le bon et il a donc choisi de se baser sur la série (robuste et éprouvée) FreeBSD 4.x pour la faire évoluer. Le but final est d'obtenir un système à image unique pour les clusters (un seul OS pour n machines) au lieu d'un cluster traditionnel (n OS pour n machines).

Voici donc, depuis le 7 janvier, la version 1.4 de ce système original.

Les nouveautés essentielles concernent une mise à jour profonde de la librairie C et l'introduction du système de packages de NetBSD (PKGSRC). Le compilateur par défaut est maintenant GCC 3.4 (la série 2.95 n'est plus supportée). Le démon NTP (synchronisation du temps) est DNTPD et il devient spécifique à cet OS. TLS (Thread Local Storage) est maintenant en espace utilisateur et les programmes peuvent donc l'utiliser directement (qu'ils soient multithreadés ou pas).

La liste des améliorations et des corrections de bugs est importante et Matt Dillon annonce que cette version 1.4 est la meilleure de toute sur le plan de la stabilité. La seule architecture supportée reste x86 mais un port vers x86-64 a démarré. Dans le cas d'un ordinateur multiprocesseurs la solution logicielle habituelle est l'implantation d'un gros verrou (Big kernel lock) qui empêche deux tâches d'accéder simultanément au noyau. Pour améliorer les performances le système FreeBSD 5.x utilise des verrous fins locaux (mutex pour mutual exclusion). C'est un système extrêmement compliqué et le code est difficile à maintenir.

Selon Matt Dillon cette complexité extrême de FreeBSD 5.x (avec son nouveau modèle de processus, son ordonnanceur de nouvelle génération, l'implémentation de verrous locaux pour les processus au détriment du verrou global, etc.) va empêcher l'obtention d'une grande fiabilité.

Pour DragonFlyBSD c'est la voie de la simplicité qui a été retenue. Le système (LWKT pour Light Weight Kernel Threads) utilise un ordonnanceur par CPU (les processus sont donc compartimentés dans leur CPU) et ils ne peuvent migrer qu'exceptionnellement avec un inter-processor interrupt (IPI). Les mutex de FreeBSD sont remplacés par des sortes de jetons logiciels (serialized tokens) qui garantissent à un ensemble de threads qu'ils ne tourneront jamais en même temps à condition qu'ils ne bloquent pas dans un appel système.

L'avantage principal de LWKT est que la mémoire cache des processeurs est mieux utilisée puisqu'elle duplique beaucoup moins d'informations. Le code est également plus simple, plus lisible et plus maintenable.

Matt Dillon a également beaucoup d'idées originales et singulières pour les versions futures de DragonFlyBSD (en particulier la réécriture du système de fichier virtuel en userspace et utilisant LWKT).

Cet OS mérite certainement qu'on s'y intéresse.

Aller plus loin

  • # Et la mascote?

    Posté par  (site web personnel) . Évalué à 3.

    Et pour la mascote y aura un super dragon qui crache des flammes et tout?
    Ce serait argument de poid ça quand même...
  • # Motivation?

    Posté par  (site web personnel) . Évalué à 7.

    Une petite question (je viens de parcourir le site de DragonFly) : quel est exactement le "positionnement" de DragonFly BSD par rapport aux autres BSD libres?

    Pour l'instant, j'avais : (merci de commenter ;-))
    - NetBSD : portabilité, propreté du code (qualité du code prioritaire sur l'implémentation de la fonctionnalité)
    - OpenBSD : sécurité à tout prix (ou presque)
    - FreeBSD : mix des deux précédents, avec accent mis sur la fonctionnalité

    Puis-je rajouter :
    - DragonFly BSD : multi-processeur/multi-tâches, expérimenter des nouvelles voies?
    • [^] # Re: Motivation?

      Posté par  (site web personnel) . Évalué à 8.

      Oui et non.
      Le multi-processeur/multi-tâches c'est aussi et surtout le credo de FreeBSD puisqu'il se focalise sur les performances.
      Pour DragonFlyBSD je dirais qu'un positionnement clair n'a pas encore emergé (du fait de la jeunesse du projet) mais que, d'après les textes de Matt Dillon, ce serait "la performance et l'innovation mais en gardant le code simple".....autrement dit c'est pas gagné pour s'insérer dans le paysage !
      Au moment du fork j'y croyais pas trop mais finalement le projet avance et y'a du traffic sur les mailing-lists.
  • # Commentaire supprimé

    Posté par  . Évalué à 5.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Section de la dépêche

      Posté par  (site web personnel) . Évalué à 5.

      Ben j'ai hésité mais ça aurait été faux de le mettre dans la catégorie FreeBSD et y'avait pas de catégorie DragonFlyBSD...alors j'ai choisi la section noyau.
      C'est pas très important de toute façon.
  • # Petite Correction TLS

    Posté par  . Évalué à 10.

    TLS ne correspond pas ici à Transport Layer Security mais à Thread Local Storage, c'est à dire la possibilité d'avoir des variables globales mais différentes pour chaque thread.
    Description sur wikipedia : http://en.wikipedia.org/wiki/Thread-local_storage
    Le paper : http://people.redhat.com/drepper/tls.pdf
    • [^] # Re: Petite Correction TLS

      Posté par  (site web personnel) . Évalué à 4.

      Je savais que j'allais faire au moins une connerie malgré les relectures...pfff...et en plus j'ai mis un petit drapeau anglais pour le lien vers fr.wikipedia. Le boulet.
      Merci beaucoup pour cette correction !
      • [^] # Re: Petite Correction TLS

        Posté par  (site web personnel) . Évalué à 4.

        Euh... Patrick... des boulets, y'en a plein qui ont relu avant de modérer... ;-)
        Donc voilà, corrigé le drapeau parceque c'est facile...
        Corrigé l'acronyme de TLS aussi, mais la phrase a-t-elle un sens maintenant ?
        • [^] # Re: Petite Correction TLS

          Posté par  (site web personnel) . Évalué à 2.

          Merci pour les corrections.
          Oui la phrase continue d'avoir un sens (essentiellement parceque je l'ai entièrement pompée sur l'annonce en anglais et que je me suis contenté de traduire : Implement direct TLS support for programs whether threaded or not.).
  • # Matt Dillon

    Posté par  . Évalué à 5.

    A ben voila pourquoi on le voit plus au cinéma Matt Dillon ! Il est trop occupé à programmer !
    • [^] # Re: Matt Dillon

      Posté par  . Évalué à 1.

      Dans un même ordre d'idée, qu'est-ce qu'il est fort Alan Cox, contribuer à la fois à FreeBSD et à Linux..
  • # DragonFly_F_BSD ?

    Posté par  . Évalué à 1.

    C'est une coquille ? j'ai suivi vite fait les liens donnés dans l'article, et je ne retrouve nulle part cette dénomination...
  • # Multithread

    Posté par  (site web personnel) . Évalué à 2.

    Si j'ai bien tout compris (c'est pas gagné :), avec DFBSD tous les threads d'un même processus s'exécutent sur le même CPU. Alors que même la machine de monsieur Tout-le-monde a tendance à devenir multicore/multiproc, n'est ce pas "petit bras" comme façon de faire (je ne dis pas ça méchamment, je suis sûr que les gars de DFBSD sont très compétents) ?
    En même temps je ne connais pas le nombre de grosses applis du libre qui sont lourdement multitreadées (du genre des threads à 100 % du CPU pendant plusieurs secondes) et qui seraient donc pénalisées...
    • [^] # Re: Multithread

      Posté par  (site web personnel) . Évalué à 2.

      Quand on dit que "tous les threads d'un même processus s'exécutent sur le même CPU" cela signifie qu'ils s'exécutent tous dans le même core. Si t'a un dual-core t'aura un thread dans le core 1 et un autre thread dans le core 2...DFBSD profite donc pleinement des applications multithreadés.
      • [^] # Re: Multithread

        Posté par  (site web personnel) . Évalué à 2.

        Heu, il me semble que tu te contredis (mais j'ai pu mal comprendre) : tu dis "tous dans le même core" puis "un thread dans le core 1 et un autre thread dans le core 2".
        Je reste donc sur mon impression de 'tous dans le même core', donc un problème potentiel de perfs avec du multithread (ce qui a entraîné les choix de la branche 5 de FreeBSD).
        • [^] # Re: Multithread

          Posté par  (site web personnel) . Évalué à 3.

          Je suis loin d'être un spécialiste. Je te colle l'extrait de wikipedia :

          In DragonFly, threads are locked to CPUs by design, and each processor has its own LWKT scheduler. Threads are never preemptively switched from one processor to another; they are only migrated by the passing of an "Interprocessor Interrupt" (IPI) message between the CPUs involved. Interprocessor thread scheduling is also accomplished by sending asynchronous IPI messages. One advantage to this clean compartmentalization of the threading subsystem is that the processors' on-board caches in SMP systems do not contain duplicated data, allowing for higher performance by giving each processor in the system the ability to use its own cache to store different things to work on.

          The LWKT subsystem is being employed to partition work among multiple kernel threads (for example in the networking code; one thread per protocol), reducing contention by removing the need to share certain resources among various kernel tasks. This thread partitioning implementation of CPU localization algorithims is arguably the key differentiating feature of DragonFly's design.
          • [^] # Re: Multithread

            Posté par  (site web personnel) . Évalué à 2.

            Si j'ai bien compris c'est cette phrase dans la news qui pose probleme:
            (les processus sont donc compartimentés dans leur CPU)


            Ce qui laisse à penser que tous les threads du processus restent sur le même Core. Du coup ça a peu d'interet pour les applis qui ont générallement 1 processus lancant moultes threads.

            Mais au vue de la citation de Wikipedia, il semble que ce soit les threads et non les processus qui soient cantonés à 1 Core.

            J'ai bon ?
  • # BSD Pour les nuls

    Posté par  . Évalué à 1.

    Salut
    Histoire de satisfaire ma curiosite
    savez vous ou je peux trouver un portrait de famille bsd ecrit en langage humainement comprehensible

    Sous entendu pas d'explication technique sur la vie intime du kernell
    Mais plutot des resumer disant

    tel bsd pour une machine de bureau
    tel bsd pour un serveur web
    tel bsd pour un serveur de calcul
    tel bsd pour un cluster
    tel bsd pour ...
    etc ...

    Puisque les bsd on en parle beacoup mais finalement dans quel domaines c'est interessant et dans quel domaine ca ne l'est pas ?

    Merci
    • [^] # Re: BSD Pour les nuls

      Posté par  (site web personnel) . Évalué à 3.

      Puisque les bsd on en parle beacoup mais finalement dans quel domaines c'est interessant et dans quel domaine ca ne l'est pas ?

      Juste une pierre à l'édifice que d'autres vont construire : j'utilise personnellement NetBSD par rapport à Linux parce que je préfère le système un peu centralisé de développement par rapport au modèle cathédrale de Linux.
      Ainsi, l'évolution d'un noyau NetBSD est relativement lente, et les développeurs réfléchissent à 4 fois avant d'intégrer une fonctionnalité ou un pilote. Les API du noyau évoluent très peu.
      Le revers de la médaille : le "quick & dirty" est, dans les noyaux "stables" (pas la version CVS en développement), peu ou prou présent, alors que c'est parfois le cas dans le noyau Linux. Et même dans les version dites stables (e.g. le coup du
      #ifdef ALPHA
      #define U32 unsigned int
      #else
      #define U32 unsigned long
      #endif
      dans un pilote SCSI du noyau 2.4.9)
      Pour avoir parcouru le code, je le trouve personnellement plus "propre" que celui de Linux (relativement bien commenté, un style d'écriture de bout en bout, ...).

      Mais ce modèle de développement a son revers de médaille : la lenteur d'intégration des fonctionnalités fait que certaines choses ne sont pas encore dans le noyau (e.g.: pas de SMP sous NetBSD alors que cela fait des lustres que c'est présent sous Linux!).

      Personnellement, si j'utilise encore Linux, c'est parce que j'ai du matériel ou des applications qui ne peuvent pas tourner sous NetBSD, trop méconnu de certains constructeurs ou développeurs.

      En gros, pour des applications qu'on a le temps de valider proprement, qui ont un passé connu, NetBSD fait très bien l'affaire, par contre, pour celui qui veut rester à la pointe de la technologie (matérielle/logicielle), Linux s'en sort souvent beaucoup mieux!
      • [^] # Re: BSD Pour les nuls

        Posté par  . Évalué à 4.

        >je préfère le système un peu centralisé de développement par rapport au modèle cathédrale de Linux.

        C'est pas plutôt par rapport au modèle *bazar* de Linux ? Et cathédrale de NetBSD ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.