Journal addr.sun_family = AF_DBUS;

Posté par  (site web personnel) .
Étiquettes : aucune
20
16
sept.
2010
http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-f(...)

Voici un nouveau type de socket proche des sockets Unix et ayant pour but d'améliorer les perfs de Dbus.

Le but est de ne plus utiliser dbus-daemon pour faire transiter les messages, son role sera alors d'activer le système d'IPC et d'authentifier les applications (si j'ai bien compris).

Voila, le gain de performance n'est pas extraordinaire mais bon, c'est déjà ça de pris!

  • # Perfs smartphones

    Posté par  . Évalué à 6.

    L'interet de ce gain de performance est beaucoup plus evident sur les smartphones etant donne la puissance limitee de ces petites bestioles.

    Faire un gain x3 sur N900 (et cela doit etre comparable sur Android), c'est quelque chose qui va vraiment dans le bon sens.

    • [^] # Re: Perfs smartphones

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

      En fait, le gain est plus important sur N900 surtout parce que les changements de contexte "coûtent" plus sur ARM que sur une architecture x86 classique. Ce n'est pas juste une histoire de fréquence de processeur par exemple.

      Il y a aussi d'autres optimisations qui pourraient rentrer dans DBus, par exemple passer les messages en petits morceaux entre le serveur et le client (pour l'instant, DBus alloue un buffer de la taille du message, ce qui fait très mal sur des très gros messages). J'en profite pour me faire de la pub (honteusement) pour un rapport sur les perfs de DBus que j'avais publié il y a quelque temps: http://blogs.gnome.org/abustany/2010/05/20/ipc-performance-t(...)

      Le projet kdbus en est au stade de prototype, j'espère que ça finira un jour en production!

      • [^] # Re: Perfs smartphones

        Posté par  . Évalué à 2.

        > les changements de contexte "coûtent" plus sur ARM que sur une architecture x86 classique.

        Ca doit dépendre de la version de l'ARM, non?
        Suivant qu'ils aient un "tagged TLB" ou pas, je pense..

        Parce que sinon je ne vois pas pourquoi les changement de contexte couteraient plus cher sur un ARM que sur un x86, mis à part peut-être le nombre de registres (et encore c'est du 32*32bit alors que pour un x86 ça peut être du 16*64bit == égalité).

        • [^] # Re: Perfs smartphones

          Posté par  . Évalué à 3.

          32 registres pour l'ARM? R0-R12 + PC + CPSR ça fait plutôt 15, non?

          Sinon j'aimerais bien connaitre aussi le pourquoi de la différence entre les changements de contexte.

          • [^] # Re: Perfs smartphones

            Posté par  . Évalué à 2.

            Oups, tu as raison je confonds avec les autres RISCs comme le MIPS et l'Alpha (qui ont 32/31 registres mais 64bit).

            Décidèment j'aime de moins en moins le jeux d'instruction ARM:
            -toujours pas de 64bit juste une variante de PAE,
            -pas de TRAP sur dépassement entier comme le MIPS..

            • [^] # Re: Perfs smartphones

              Posté par  . Évalué à 4.

              N'ayant (à peu près) rien compris à tes 2 reproches, aurais-tu l'amabilité d'expliquer aux noobs (dont je fais clairement partie) ce que tout cela signifie, ce qui manque/ne se fait pas comme tu le souhaiterais, comment fait la concurrence, ... ?

              Merci.

              • [^] # Re: Perfs smartphones

                Posté par  . Évalué à 5.

                pas de 64bits, ça veut dire que c'est toujours en 32 bits avec une variante de PAE qui était la technique utilisée pour avoir plus de 4Gb de mémoire sur son PC avec un x86 en 32 bits.

                Le trap en MIPS, c'est, si je me souviens bien, un mécanisme du processeur (pas d'un langage) qui permet de générer une exception en cas d'overflow.

                « 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: Perfs smartphones

                  Posté par  . Évalué à 5.

                  Tout à fait:
                  1) avant les ARMs étaient limités à 4Go de mémoire totale, maintenant avec la dernière variante de leur jeux d'instruction ARMv7 ils sont uniquement limités à 4Go par processus, mais ils peuvent avoir jusqu'à 256Go de mémoire totale (40bit).
                  Ce qui fait que s'ils veulent vraiment cibler les serveurs, il faudra qu'ils changent encore leur jeu d'instruction pour autoriser plus de 4Go par processus..

                  2) le MIPS possède 2 variantes de chaque instruction entières une avec ou sans TRAP en cas de débordement entier.
                  Le TRAP est grosso-modo l'équivalent d'une exception mais gérée directement par le CPU.

                  L'avantage est que, en Ada par exemple, cela permettrait de générer une exception en cas de débordement entier sans avoir à rajouter de code dans le chemin 'normal' (sans débordement): gain en efficacité..
                  Et je trouve que le comportement d'Ada bien plus sain que celui du C qui peut causer des problèmes de sécurité, donc j'aime bien le MIPS..

                  • [^] # Re: Perfs smartphones

                    Posté par  . Évalué à 3.

                    Je vais me faire le défenseur du ARM. En ce qui concerne le 64bits, le principal but de l'ARM est de réduire la consommation et la taille au maximum, donc le choix de faire une croix dessus se tient tout à fait, vu le faible nombre d'application qui pourrait en tirer parti... mais maintenant que le besoin de serveurs basse consommation se fait sentir, peut être que ça va changer?

                    Pour les débordements, il est assez simple de le faire en assembleur ARM, par ex en rajoutant un SWIVS après une addition (enfin, je crois... essayez de tester avant si vous devez l'intégrer au contrôleur de vol d'Ariane). Et c'est vrai qu'en C, l'absence de vérification intégrée au langage manque cruellement ; à ma connaissance, il n'existe par exemple aucune extension digne de ce nom à gcc (il y a bien -trapv, mais il n'est pas possible de gérer au cas par cas).

                    • [^] # Re: Perfs smartphones

                      Posté par  . Évalué à 2.

                      Pour les débordements, tu peux rajouter des tests dans tout les CPUs..
                      Mais ils augmentent la taille du code, utilisent des ressources pas beaucoup étant non pris normalement), le coté élégant du MIPS est que cela ne coute rien (*)!

                      *: enfin dans le cas normal de non-débordement.

                  • [^] # Re: Perfs smartphones

                    Posté par  . Évalué à 2.

                    L'avantage est que, en Ada par exemple, cela permettrait de générer une exception en cas de débordement entier sans avoir à rajouter de code dans le chemin 'normal' (sans débordement): gain en efficacité..

                    Agrandir le jeu d'instructions juste pour faciliter l'optimisation d'un langage hyper-marginal ? Étonnant qu'ils n'aient pas pris cette décision, en effet...

                    • [^] # Re: Perfs smartphones

                      Posté par  . Évalué à 3.

                      <soupir un linuxien devrait le savoir>
                      Une bonne idée est une bonne idée, quelque soit le nombre d'utilisateurs!

                      Le comportement du C de masquer les débordements entier est une connerie, j'espère que le langage qui le remplacera un jour ne reproduira pas cette erreur..

      • [^] # Re: Perfs smartphones

        Posté par  . Évalué à 10.

        "Le projet kdbus"
        Comme d'hab', on voit que l'innovation vient de KDE !


        ====>[]

  • # Microkernel ?

    Posté par  . Évalué à 1.

    N'y a-t-il que moi à qui ce système fait penser que linux penche de plus en plus vers un système genre microkernel ?
    Je veux dire, un système de messages inter-processus (IPC) dans le kernel « normalisé » pour tout l'OS, c'est quand même plutôt typique du microkernel.

    C'est marrant l'évolution de l'informatique, des fois !

    • [^] # Re: Microkernel ?

      Posté par  . Évalué à 5.

      Si le Hurd ne vient pas à nous, nous irons à lui.

    • [^] # Re: Microkernel ?

      Posté par  . Évalué à 10.

      On déplace du code en espace utilisateur vers du code noyau pour éviter du context switching.

      Je doute qu'on puisse raisonnablement en conclure qu'on tend vers du microkernel.

      La caractéristique des micro-noyaux ce n'est pas d'avoir un système d'IPC, puisque tous les noyaux en ont un ; c'est que :

      - ce soit l'une des rares fonctionnalités offertes ("idéalement" le noyau ne fait que gérer les contextes d'exécution, donc ordonnancement des processus, communication entre les processus et gestion de l'addressage mémoire) ;
      - qu'elle soit performante (puisque les tâches habituellement effectuées par le noyau le seront par une flotte de processus qui en aura donc beaucoup beaucoup besoin, des IPCs).

      Je ne trollerai ni sur le nombre de fonctionnalités traînant dans le noyau, ni sur les performances de D-Bus.

      Ceci dit ici le leitmotiv du changement c'est que le context switching coûte trop cher.
      C'est en partie dû au design du noyau Linux.

      Au contraire, les micro-noyaux :

      - utilisent énormément de context switching puisqu'un tas de processus sont impliqués pour fournir une fonctionnalité qui est classiquement entièrement gérée en kernel space ;
      - sont donc logiquement conçus pour être les plus efficaces possibles en la matière.

    • [^] # Re: Microkernel ?

      Posté par  . Évalué à 8.

      N'y a-t-il que moi à qui ce système fait penser que linux penche de plus en plus vers un système genre microkernel ?

      Je ne suis pas d'accord : dans un micro-noyau, il y a l'idée de minimiser le code résidant en mode noyau et d'écrire tout ce qu'on peut sous forme de processus utilisateurs asynchrones communicant par passage de message. En l'occurrence on fait à peu près l'inverse : au lieu de déplacer ce qui devrait traditionnellement être en espace noyau (pilotes, FS...) vers l'espace utilisateur, on remonte une couche plutôt applicative (un bout de DBus) dans le noyau !

      Je veux dire, un système de messages inter-processus (IPC) dans le kernel « normalisé » pour tout l'OS, c'est quand même plutôt typique du microkernel.

      Et les sockets de grand-papa alors, certes plus bas niveau que DBus, elles comptent pour du beurre ?

  • # socket

    Posté par  . Évalué à 3.

    Et pourquoi ont ne peut réutilisé les sockets actuel et faire passer DBUS dessus ?

Suivre le flux des commentaires

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