Journal [TOI AUSSI] Viens prendre un cours de programmation système

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
26
11
oct.
2012

On parle de DragonFly BSD.

Tout commence cet été lors du GSoC. Mihai Carabas a travaillé sur la prise en charge avancée de la topologie des processeurs. En gros, cela permet de faire la différence entre un socket, un core et un thread. Le monsieur qui porte le nom d’un acteur de cinéma a alors eu deux trois idées sur la façon dont l’ordonnanceur de processus pouvait en tirer parti.

Puis, il y a eu ce banc d’essai qui a déclenché pas mal de discussions.

Finalement, Matt a travaillé sur les sockets, Unix, sur le tampon de cache, écrit un nouvel ordonnanceur et deux ou trois autres babioles qu’il explique dans ce courriel.

Le résultat ressemble à ça :
BENCH

Je ne saurais, une fois de plus, que trop recommander ce projet sympathique à tous ceux qui aiment la belle programmation système. Que ce soit pour participer, tester ou simplement suivre et apprendre. La version 3.2 est en cours de débogage. À bon entendeur…

  • # bench complet

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

    Pour ceux que ça intéresse, le bench complet est là :
    http://lists.dragonflybsd.org/pipermail/users/2012-October/017536.html

  • # Taille des diff

    Posté par  . Évalué à 4.

    Finalement Matt a travaillé sur les socket, unix, sur le buffer cache, écrit un nouvel ordonnanceur et deux trois autres babioles qu'il explique dans ce mail

    Si tout est vraiment dans les liens que tu as donné, il a fait le tout en moins de 1 200 lignes (dont plus de 900 pour l’ordonnanceur). Le rapport gain/taille des diff est énorme !

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Taille des diff

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

      Le rapport gain/taille des diff est énorme !

      Ceci dit l'ensemble de l'infra pour utiliser les processus légers et les verrous à grain fins et les io non bloquantes est déjà en place. Le gros du travail à finalement été de trouver ce qui coinçait. De plus il ne faut pas oublier le commit sur la topologie des CPU qui fait environ 1300 lignes.

      http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff_plain/f77c018a1c4b5e9271cf5fcf3912c2ccbea9c0e1

      • [^] # Re: Taille des diff

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

        Le rapport gain/taille des diff est énorme !

        Je rajouterai qu'on sent une évolution psychologique de taille. Considérer l'amd64 comme une vrai architecture et plus comme un x86 amélioré.

      • [^] # Re: Taille des diff

        Posté par  . Évalué à 5.

        Le gros du travail à finalement été de trouver ce qui coinçait.

        C'était ce que je voulais mettre en avant. Il a pas réécris des algo monstrueux, c'est juste l'implémentation d'une idée « simple ».

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Scientific Linux

    Posté par  . Évalué à 3.

    Pourquoi Scientific Linux est-il aussi bon ?

    Est-ce que c'est juste que Linux a été optimisé, ou non, le noyau de Scientific Linux est patché ?

    Knowing the syntax of Java does not make someone a software engineer.

    • [^] # Re: Scientific Linux

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

      disons que le codeur BSD a trouvé linux très bon et s'est demandé pourquoi.

      "La première sécurité est la liberté"

    • [^] # Re: Scientific Linux

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 11 octobre 2012 à 12:00.

      Est-ce que c'est juste que Linux a été optimisé, ou non, le noyau de Scientific Linux est patché ?

      Scientific Linux est un clone de rhel ( ~ Centos). Le noyau est donc celui de red-hat. Le test basé sur pg_bench à pour but d'évaluer les performances au niveau SMP. Grosso-modo on fait monter le nombre de process et on regarde comment ça réagi. C'est un cas bien particulier notamment parce que les clients sont sur la même machine que les serveurs.

      En fait il apparaît que trois points sont essentiels :

      • l'ordonnancement
      • la gestion des sockets (l'effondrement de NetBSD vient probablement de là).
      • la gestion de la mémoire partagée

      Il s'est avéré que sur ce test Linux et OpenSolaris ont toujours été en tête. Mon hypothèse est que ces noyaux, de part leur utilisation industrielle dans un contexte massivement multiprocesseur sont largement plus optimisés pour ce contexte que les noyaux BSD. Je pense également que FreeBSD souffre beaucoup d'un certain conservatisme dans ses réglages par défaut.

      En fait ce qui est important ici, je crois, ce n'est pas que Linux soit meilleur ce qui semble normal vu l’ampleur comparée des projets mais que DragonFlyBSD avec ces 12 bonhommes arrive à réaliser.

      • [^] # Re: Scientific Linux

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

        Je pense également que FreeBSD souffre beaucoup d'un certain conservatisme dans ses réglages par défaut

        Ça serait intéressant que tu donnes des détails là

        • [^] # Re: Scientific Linux

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

          Ça serait intéressant que tu donnes des détails là

          Je peux te donner quelques exemples.

          • kern.maxusers limité à 384, soit la même valeur sur un Core2 avec 2GO de ram que sur un 32 coeurs avec 64GO.
          • kern.ipc.shm_use_phys est désactivé par défaut
          • kern.ipc.maxpipekva ou encore vfs.maxbufspace sont souvent juste alors qu'il y a de la mémoire dispo.
          • tout ce qui est semaphores et mémoire partagée est extrêmement limité par défaut (voir postgres ou mod_fcgid par exemple).

          Ce que je voulais dire avec cette remarque c'est qu'a mon avis, il est tout à fait possible à FreeBSD de tenir le haut du pavé sur ce type de benchs. Mais que cela demande un gros travail de tuning.

          .

  • # Transmission de code

    Posté par  . Évalué à 4.

    Je sais que les BSD se "donne" souvent du code. Es-ce que cette amélioration va pouvoir profiter à tous les BSD ?

    En tous cas bravo, ça me rappelle la "petite" amélioration des "cgroups" dans linux qui apportait un gain significatif en multitâche intensif.

    • [^] # Re: Transmission de code

      Posté par  . Évalué à 2.

      Vu ce qu'ils ont changé: des parties dans le vfs, dans l'ordonnanceur,… ça va être trop chaud de récupérer, ce n'est pas un driver là.

      Par contre ce qui m'inquiète c'est que Net s'effondre avec un critical temperature shuttting down…

  • # Mailling list

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

    Je suis le seul à trouver qu'une mailing list est un très mauvais moyen de communication…

    Aussi bon qu'est l'information, j'ai pas envie d'aller fouillé trois plombe là dedans pour en ressortir un truc qui m'intéresse.

    La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

    • [^] # Re: Mailling list

      Posté par  . Évalué à 7.

      En même temps si les BSD savaient communiquer ils ne seraient pas morts…

      • [^] # Re: Mailling list

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

        En même temps si les BSD savaient communiquer ils ne seraient pas morts…

        Rhoooo. Pas morts, juste fatigués.

        • Pre-order en cours pour OpenBSD-5.2 (sortie début novembre si je ne m'abuse)
        • FreeBSD vient de sortir la release canditate 2 de la 9.1 (9.1-RC2)
        • NetBSD avance sur sa 6.0

        Je ne suis pas DragonFly ni NetBSD alors je ne suis pas au courant.

        Comme le souligne un article plus haut, à mon avis ils font du sacré bon boulot avec pas grand chose comme moyen.

        les pixels au peuple !

        • [^] # Re: Mailling list

          Posté par  . Évalué à 1.

          Rhoooo. Pas morts, juste fatigués.
          FreeBSD vient de sortir la release canditate 2 de la 9.1 (9.1-RC2)

          Passer de 7 à 9 en 6/7 ans (quand j'ai arrêté d'utiliser) ça tient quand même plus de la mort cérébrale que de la sieste.

          Comme le souligne un article plus haut, à mon avis ils font du sacré bon boulot avec pas grand chose comme moyen.

          J'ai pas dit le contraire. Ceux qui ont plussés ont compris le trait d'humour (enfin j'espère).

          • [^] # Re: Mailling list

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

            Passer de 7 à 9 en 6/7 ans (quand j'ai arrêté d'utiliser) ça tient quand même plus de la mort cérébrale que de la sieste.

            Damned, ça passe donc si vite ?

            "FreeBSD 7.0-RELEASE Announcement, Date: Wed, 27 Feb 2008 17:19:52 -0500, From: Ken Smith kensmith@FreeBSD.org"

            Pas tout à fait 5 ans seulement. Un peu moins de deux ans entre deux releases majeures donc. Vu les évolutions ça me paraît correcte (surtout que les cycles de releases sont toujours assez long chez FreeBSD)

            J'ai pas dit le contraire. Ceux qui ont plussés ont compris le trait d'humour (enfin j'espère).

            Oui j'avais bien compris, on est sur dlfp quand même :-)

            les pixels au peuple !

            • [^] # Re: Mailling list

              Posté par  . Évalué à -1.

              Damned, ça passe donc si vite ?

              Oui grave mais c'est vrai que j'ai triché d'un cycle entre 7-CURRENT et 9-STABLE. Vu que FreeBSD avance tellement lentement que t'es obligé de tourner en -CURRENT c'est de bonne guerre ;)

    • [^] # Re: Mailling list

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

      Je suis le seul à trouver qu'une mailing list est un très mauvais moyen de communication…

      Oui tu es le seul. Tu suggères quoi pour permettre à des milliers de personnes vivants sur des fuseaux horaires différents pour communiquer (ce qui implique que tout un chacun puisse envoyer des articles et répondre) ? Une mailing pour ça c'est bien pratique (et qu'on ne me parle pas des horribles forums web).

      Si ce n'est que pour l'information, tu as DLFP pour ça.

      les pixels au peuple !

      • [^] # Re: Mailling list

        Posté par  (Mastodon) . Évalué à 5.

        Une mailing pour ça c'est bien pratique

        Mieux : un (ou plusieurs) serveur NNTP :)

      • [^] # Re: Mailling list

        Posté par  . Évalué à 2.

        Le gros problème des mailings list, ce sont les archives. Comme il n'y a pas moyen de taguer les messages ou de voter pour, il est très difficile de chercher un message. Même chose quand on reçoit 42 messages par jour et qu'il faut faire le tri qui nous intéresse. Je ne sais pas s'il y a d'autres moyens plus performant, mais les mailings list ne sont clairement pas adaptées.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Mailling list

        Posté par  (site web personnel) . Évalué à -1. Dernière modification le 12 octobre 2012 à 11:23.

        Franchement un forum pour poser des questions et un wiki pour "archiver" les réponses utiles, ça passe bien mieux.

        Au final, une mailing list, c'set un moyen un peu égoïste de faire tourner de l'information sachant que celle-ci ne sera jamais communiquer à ceux qui n'en sont pas.

        La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

Suivre le flux des commentaires

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