La fin du verrou global dans le noyau Linux ?

Posté par (page perso) . Modéré par Jaimé Ragnagna.
Tags : aucun
1
18
mai
2008
Linux
Connu sous le nom de "Big Kernel Lock" (BKL) ou encore de "Giant Lock", le verrou global du noyau est une technique permettant de rendre un système d'exploitation compatible avec l'emploi de machines multiprocesseurs.
Récemment un problème de régression de performances est venu remettre en lumière le BKL et raviver l'intérêt dans la difficile tâche consistant à le supprimer entièrement du noyau Linux.
Les discussions sur la liste de diffusion ont été vives avant que Linus ne choisisse une orientation. Maintenant c'est un travail de longue haleine qui va commencer afin d'en finir une bonne fois pour toute avec le verrou géant du noyau. Conceptuellement la technique du verrou global du noyau est simple. Quand une machine multiprocesseur (SMP) est utilisée il faut mettre en place un mécanisme empêchant les divers processeurs d'effectuer des actions contradictoires au même moment ou d'accéder aux mêmes ressources simultanément. Imaginons par exemple qu'un programme utilisateur déclenche un appel système et que le processus entre alors en espace noyau pour effectuer l'action demandée. Comment être certain que l'autre processeur n'est pas en train d'exécuter un code qui demande, lui-aussi, à entrer en espace noyau ? La solution la plus simple à ce problème est que le premier processus pose un verrou derrière lui dès qu'il entre dans l'espace mémoire du noyau. Ainsi le code s'exécutant sur l'autre processeur ne pourra pas entrer et faire des choses contradictoires.

L'avantage du verrou global du noyau est donc qu'il est très simple et très facile à mettre en place. Comme beaucoup de tâches vivent de toute façon la majeure partie de leur temps en espace utilisateur cela ne pose pas trop de problèmes d'utiliser le "Giant lock" et, avec une machine multiprocesseurs, on obtient quand même une plus grande rapidité d'exécution.
Le désavantage c'est que cette solution fait perdre, pour certaines tâches, une bonne partie des bénéfices associées à l'utilisation d'une machine SMP. Les programmes faisant un appel fréquent au noyau sont pénalisés par le "Giant lock". Comme le code du second processeur attend patiemment à la porte du noyau que le premier processus déverrouille l'entrée on perd beaucoup en rapidité. Encore pire : Imaginez une coûteuse machine octoprocesseurs avec un seul coeur faisant son travail en espace noyau alors que les sept autres se roulent les pouces en attendant l'ouverture du verrou !

La vraie solution au problème des accès simultanés au noyau n'est donc pas le verrou global. Ce ne peut être qu'une simple solution provisoire en attendant mieux. Mais qu'est-ce qui serait mieux ? On pourrait par exemple, à l'intérieur du noyau, isoler les blocs faisant des choses différentes et permettre de mettre des petits verrous sur chacun des blocs. Par exemple si un processus entre en espace noyau pour accéder au système de fichiers il ne posera qu'un verrou sur le système de fichiers. Ainsi un autre processus s'exécutant sur un autre processeur pourra entrer en espace noyau pour accéder, par exemple, à la pile réseau. Il lui suffira de poser son verrou à lui sur la pile réseau et il n'y aura aucun risque d'actions contradictoires. Pour aller plus loin on fragmentera la pile réseau elle-même en sous-parties afin de pouvoir poser des verrous sur ces sous-parties, etc.
On voit que cette idée tend à décomposer conceptuellement le noyau en blocs fonctionnels de plus en plus petits afin de poser des verrous qui ne bloquent que le minimum de fonctions. Ce "fine-grained locking" (verrouillage à grains fins) est donc bien plus efficace que le verrou global du noyau et ce dernier est progressivement éliminé des systèmes d'exploitation modernes.
L'ennui c'est que l'implémentation du verrouillage à grains fins est très difficile et que le risque d'introduction de bugs subtils est très élevé. Cela prend donc du temps de convertir un système d'exploitation et l'élimination du verrou global est un projet de longue haleine.
Le noyau Linux a évolué progressivement au fil des années afin de réduire au maximum les appels au verrou global et, de la même façon, FreeBSD a lancé le projet SMPng pour introduire le verrouillage à grains fins à partir des versions 5.x. La majorité des blocs fonctionnels importants de ces noyaux sont désormais libérés du "Giant Lock" et tout le code critique pour les performances s'exécute avec le système de verrouillage à grains fins.
Certes il reste de nombreux appels au verrou global disséminés dans tout le noyau mais ces appels sont dans des parties anciennes du noyau et personne n'a vraiment envie d'aller mettre son nez dedans car de toute façon cela n'impacte pas les performances. Comme l'a écrit en 2004 Jonathan Corbet : "Changer le vieux code employant le BKL n'est pas un exercice de timides. Dans la plupart des cas l'attitude la plus prudente a été de simplement laisser les choses en l'état".
La situation était d'autant moins urgente qu'Ingo Molnar avait modifié le verrou géant pour qu'un thread en attente puisse obliger celui s'exécutant en mode noyau a interrompre son travail, à sortir du noyau et à libérer le verrou. Cette modification (techniquement Ingo a transformé le verrou géant en un sémaphore) avait pour but de réduire les latences générées par le "Giant lock". En permettant de préempter les divers appels au verrou géant restant dans le noyau tout le monde pensait qu'on en avait enfin fini avec cet empoisonnant casse-tête.

C'est pour cette raison que le message que Yanmin Zhang a posté le 6 mai sur la liste de diffusion Linux a causé une certaine consternation. Selon un test de performances, nommé AIM7, Yanmin Zhang a constaté une dégradation de 40% de la rapidité d'exécution entre le noyau stable 2.6.25 et le noyau candidat 2.6.26-rc1. Il a traqué l'origine du problème et il est tombé sur ce patch rendant très générique l'implémentation des sémaphores dans le noyau. Le problème se complique un peu parce que les sémaphores ne sont plus trop utilisés dans le noyau depuis l'introduction des mutex à partir du 2.6.16.
Nous voilà donc avec un noeud de problèmes qui semble inextricable et avec peu de solutions envisageables :
  • Laisser le code tel quel car ce serait trop difficile de faire autrement. C'est difficilement acceptable du fait de la grosse régression de performances.
  • Complexifier grandement le code des sémaphores (en employant le "lock stealing") afin de restaurer les performances. Mais pourquoi compliquer ainsi l'implémentation des sémaphores alors que de toute façon il s'agit d'un vieux mécanisme qui est progressivement remplacé par les mutex ?
  • Revenir au vieux verrou géant non préemptible. Ainsi on élimine la nécessité des sémaphores (sans doute destinés à mourir de leur belle mort) et le code est bien plus propre. L'ennui c'est que les vieilles parties du noyau qui utilisent le verrou géant (l'appel système fcntl(), un certain nombre d'implémentations de l'appel ioctl(), le code TTY, ainsi que l'appel système open() pour les périphériques en mode caractère) vont avoir une plus grande latence.
Ingo Molnar avait choisi la seconde solution mais Linus a opté pour la troisième. Pour lui le retour du problème de latence est l'occasion rêvée pour en finir avec le BKL (Big Kernel Lock): "La nouvelle implémentation des sémaphores (NdT: Celle d'Ingo avec le "lock stealing") n'en vaut tout simplement pas la peine. Très franchement nous avons peut-être _besoin_ d'avoir un BKL peu performant pour en finir avec lui. Les gens ont essayé de rendre le BKL plus efficace et cela a été un échec. Plutôt que d'investir des efforts démesurés en essayant de le rendre meilleur pourquoi ne pas juste dire : Bordel - Si vous avez des problèmes avec le verrou géant vous devez bosser avec les autres pour supprimer ce BKL au lieu de tourner autour du pot !"

Comme souvent avec Linus c'est donc la solution la plus radicale et la plus propre qui est favorisée. Il va donc falloir se retrousser les manches et s'attaquer à tous les appels au verrou géant qui restent dans le noyau. C'est un travail de grande ampleur car, comme le souligne Ingo : "12 ans après que Linux ait été converti en système d'exploitation compatible avec les machine multiprocesseurs, il reste encore plus de 1300 appels au verrou géant dans le code. Plus de 400 sont des sections critiques faisant appel à lock_kernel() et il y a aussi plus de 800 appels ioctl. Ces appels sont dispersés dans des zones de vieux code et peu de gens ont une bonne compréhension de ces zones et osent les modifier. Selon une analyse rapide, à la vitesse actuelle de suppression du BKL nous allons devoir attendre plus de 10 ans pour en finir et pour retrouver une latence acceptable".

Bien entendu dans l'esprit d'Ingo il n'était pas acceptable de s'en tenir à la vitesse actuelle et il a annoncé une branche spéciale du noyau Linux nommée "kill-the-BKL" afin d'accélérer le mouvement. En gros la stratégie suivie va consister a rendre le plus facile possible la suppression des appels au verrou géant sans risquer d'introduire les bugs subtils évoqués plus haut. Le BKL est transformé en mutex géant, l'outil de déboguage lockdep est ainsi compatible et permet de détecter les situations d'interblocages. Jonathan Corbet s'est consacré pour sa part a éradiquer les appels système injustifiés au verrou géant pour les périphériques en mode caractère. En effet beaucoup de ces périphériques n'ont pas vraiment besoin du BKL et ne font appel à lui que parce que le développeur a mal écrit son code. Il suffit donc d'enlever les lignes lock_kernel/unlock_kernel dans fs/char_dev.c et de modifier les 83 pilotes faisant appel à char_dev.c.
A un moment Jonathan Corbet s'est inquiété de savoir ce qui allait arriver aux modules maintenus à l'extérieur de la branche Linux principale : "Il n'y a pas d'avertissement aux mainteneurs de modules externes que des changements doivent être fait. Donc, sans le moindre doute, un bon nombre d'entre eux vont juste continuer comme avant sans rien modifier. Et quand l'un de ces modules aura _vraiment_ besoin du BKL alors un truc horrible va arriver à quelqu'un".
Comme il était prévisible Linus ne se préoccupe pas trop des gens qui maintiennent des modules à l'extérieur de la branche principale et sa réponse a été sans pitié : "Les modules externes ont des bugs parce que les interfaces changent. Film à 11 heures.
C'est vrai, mais cela ne devrait pas nous empêcher de le faire quand même. Spécialement parce que les modules externes qui sont bien maintenus (cad dont les auteurs suivent les grandes discussions comme celle-ci) pourront simplement s'adapter et utiliser le BKL comme avant. Et en plus ce changement restera compatible avec les anciens noyaux. Bien entendu les modules bien maintenus n'utiliseraient pas le BKL de toute façon...
"

En définitive toute cette agitation sera sans doute bénéfique pour le noyau Linux. Après l'élimination progressive au fil des années du verrou géant dans tout le code critique pour les performances le travail avait été interrompu et les derniers appels non critiques stagnaient toujours dans le noyau. Pourquoi se casser la tête pour les enlever puisque cela ne changera rien à la rapidité de la machine ?
Le problème de performances soulevé par Yanmin Zhang aura donc été l'occasion de piquer au vif les développeurs et de raviver leur zèle. Comme Linus a refusé l'option tentante de cacher le BKL en complexifiant l'implémentation des sémaphores il ne reste plus qu'à s'attaquer bille en tête aux derniers vestiges du verrou géant. Le travail va se dérouler dans la branche "kill-the-BKL" mais il sera sans doute possible aux utilisateurs du noyau principal d'activer une nouvelle option (CONFIG_DEBUG_BKL) afin de participer eux aussi à la chasse aux bugs.
Avec un peu de chance ce processus ne devrait pas prendre trop de temps. Dans quelques mois le verrou géant ne devrait plus être qu'un mauvais souvenir et tous les processus pourront gambader simultanément en espace noyau.
  • # patrick_g, sors de ce corps !

    Posté par . Évalué à 9.

    Merci encore une fois pour cette superbe dépêche !
    • [^] # Re: patrick_g, sors de ce corps !

      Posté par . Évalué à 10.

      heu, cette fois c'est bien patrick_g, pas quelqu'un d'autre ! (cette phrase traditionnelle est généralement employée pour les autres contributeurs :) )

      Quoi qu'il en soit, cette dépêche est effectivement réellement passionnante, félicitation !

      On en vient à regretter que linuxfr ne soit pas plus web 2.0 avec un nuage de tags pour retrouver plus facilement les diverses dépêches de qualités en fonction de ce qu'elles contiennent.

      Pour rebondir sur le sujet, comment s'en sortent les autres systèmes d'exploitation par rapport à ce problème ? Freebsd a été brièvement évoqué, qu'en est-il de windows, solaris, mac os x par exemple ?

      Pas une mince affaire que ces histoires de Big Kernel Lock, les développeurs du noyau linux sont vraiment de sacrés hackers !

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # Bravo

    Posté par . Évalué à 10.

    Excellent article, résumant tout ce qui c'est passé avec la juste de dose de détails et d'explications.
  • # Un petit correctif

    Posté par . Évalué à 7.

    >mais Linus a opté pour la seconde.

    Non c'est la troisième dans ta liste.

    un point que je trouve perfectible aussi, c'est que dans la liste tu marque 'complexifier l'implémentation des sémaphores' ce qui aurait tendance a faire croire que ce serait nouveau, alors que ce n'est pas le cas.. Je mettrais plutôt 'revenir a l'ancienne implémentation (complexe mais performantes) des sémaphores'.

    En tout cas, merci pour le poste!
  • # Et CONFIG_PREEMPT_RT ?

    Posté par . Évalué à 9.

    Le soucis est qu'il y a un impact non négligeable sur le temps réel sous Linux. Supprimer le BKL rajoute une section non pré-emptible dans le noyau. Et cela doit donc avoir un impact sur le patch CONFIG_PREEMPT-RT d'Ingo Molnár justement.
    http://kerneltrap.org/mailarchive/linux-kernel/2008/5/14/1821774

    pl.
  • # Chapeau !!

    Posté par . Évalué à 10.

    Je dois avouer que j'ai déjà lu 2 fois des articles à propos du BKL, une fois sur kernelnewbies et une fois sur slashdot. Je n'avais pas compris grand chose...

    En revanche, cette dépèche est claire, bien structurée, et explique parfaitement l'origine du problème, le principe des solutions envisagées, les tenants et les aboutissants.... Du patrick_g en grande forme quoi !

    Merci beaucoup pour ces dépêches que je lis toujours avec grand plaisir.
  • # Et en attendant ?

    Posté par (page perso) . Évalué à 4.

    > Dans quelques mois

    Et en attendant ?

    La 26 était en rc1 donc à un statut assez avancé. Elle est retardée de quelques mois ? ou on la sortira avec la perte de perf ?
    • [^] # Re: Et en attendant ?

      Posté par (page perso) . Évalué à 8.

      >>> La 26 était en rc1 donc à un statut assez avancé. Elle est retardée de quelques mois ? ou on la sortira avec la perte de perf ?

      Il faut bien voir que la perte de perf (c'est à dire l'augmentation des latences) est très théorique. Cela ne concerne que quelques parties du noyau qui sont sous le BKL et ces parties sont peu critiques pour les perfs et très peu utilisées.

      Linus souligne que "The core kernel, VM and networking already don't really do BKL".
      • [^] # Re: Et en attendant ?

        Posté par . Évalué à 5.

        en fait le plus génant est probablement pour la latence dans des systèmes temps réels mou, avec une plus forte perturbation possible des processus (au sens large) temps réels par des processus non temps réels.
    • [^] # Re: Et en attendant ?

      Posté par . Évalué à 6.

      rc1 pour le kernel c'est tout sauf un statut avancé. Cela marque la fin de "l'innondation" (les quelques milliers de changesets qui sont mergés pendant les 2 premières semaines) et le début de la période de stabilisation.

      Il se passe encore environ 1 mois avant la sortie du kernel.
  • # Sémaphore et mutex

    Posté par . Évalué à 3.

    Tu parles de sémaphores et de mutex. Tu dis que c'est la même chose ou le laisse entendre.
    Je ne connais pas grand chose au fonctionnement interne du noyau, mais mutex et sémaphore ne sont pas la même chose.
    On peut utiliser un sémaphore comme un mutex, mais pas l'inverse. Certe, on peut implémenter les sémaphore uniquement avec les mutex, mais c'est n'est pas trivial.

    Es-ce que j'ai rien compris ou as-tu fait un raccourcis pour simplifier ?
    • [^] # Re: Sémaphore et mutex

      Posté par . Évalué à 5.

      >Tu parles de sémaphores et de mutex. Tu dis que c'est la même chose ou le laisse entendre.

      Bof, il dit juste qu'il y a un mouvement pour remplacer les sémaphore par des mutex.

      Le reste, c'est toi qui extrapoles je pense..
      • [^] # Re: Sémaphore et mutex

        Posté par (page perso) . Évalué à 2.

        C'est tiré de cete article : http://lwn.net/Articles/273731/

        Citation :
        "once upon a time (prior to 2.6.16), semaphores were one of the primary mutual exclusion mechanisms in the kernel. The 2.6.16 cycle brought in mutexes from the realtime tree, and most semaphore users were converted over. So semaphores, which were once a performance-critical primitive, are now much less so".
        • [^] # Re: Sémaphore et mutex

          Posté par . Évalué à -1.

          > C'est tiré de cete article : http://lwn.net/Articles/273731/

          In practice, that upper limit is almost always set to one, resulting in semaphores which are used as a straightforward mutual exclusion primitive.

          Dans ce contexte, je comprend.
          Mais en général on utilise pas un semaphore si on a besoin d'un mutex (c-à-d d'un simple lock). Or c'est ce que faisait Linux (pour des raisons historiques).

          Nul doute que reno savait ça...
          Mais il se l'est gardé pour lui...
        • [^] # Re: Sémaphore et mutex

          Posté par . Évalué à 5.

          De l'article :
          - "Ainsi on élimine la nécessité des sémaphores (sans doute destinés à mourir de leur belle mort)"

          Le "sans doute destinés à mourir de leur belle mort" est me semble-t-il de trop.
          Ils resteront. Au moins pour les applis qui ont besoin de sémaphore (ce qui ne peut être géré que par le noyau).
          • [^] # Re: Sémaphore et mutex

            Posté par . Évalué à 2.

            Sauf qu'on parle des semaphore kernel ici, pas des semaphores noyau.

            Les sémaphore kernel restant vont plutot etre remplacé par des waitqueue IIRC.
            • [^] # Re: Sémaphore et mutex

              Posté par . Évalué à 3.

              > Sauf qu'on parle des semaphore kernel ici, pas des semaphores noyau.

              ???
              M'enfin, je crois que je te suis.
              J'ai bien compris qu'il y a un truc que ne comprend pas :-)
              Il doit me manquer un élément pour que j'ai une vue d'ensemble cohérente.
              Enre le semaphore qui est utilisés comme des mutex mais qu'il est super compliqué de remplacé par un mutex sans pertes de perfo car le semaphore est super optimisé mutex, ce n'est pas simple.
              J'espérais qu'un commentaire ferait la lumière dans ce "bordel" (pour moi).
              Mais j'aurai dû faire plus d'effort pour comprendre et ne pas espérer que l'explication tomberait toute cuite.
  • # Vers ou ?

    Posté par . Évalué à 3.

    Tu m'as fait peur , j'ai cru qu'il était questions de DRM , dans le noyau :)
  • # et les autres OS ?

    Posté par . Évalué à 7.

    On parle un peu de FreeBSD dans la news, ils cherchent apparemment aussi à éliminer ce "verrou global"... mais qu'en est-il des autres ?

    Comment se débrouillent-ils ? Les BSD, MacOSX, Windows ?

    Par contre, je suppose que les OS temps réel comme QNX n'ont pas ce problème ?
    • [^] # Re: et les autres OS ?

      Posté par (page perso) . Évalué à 6.

      Concernant NetBSD, c'est le gros chantier de la 5.0. Beaucoup de travail a été fait par Andrew Doran sur le sujet (et aussi Mindaugas Rasiukevicius et Yamamoto Takashi). Un certain nombre de sous-système a déjà été libéré du BIG LOCK. Dans ce mail (http://mail-index.netbsd.org/current-users/2008/04/24/msg002(...) ) , Andrew Doran fait un récapitulatif de ce qui est encore sous le controle du big lock. Il reste encore du boulot, mais un travail très important a dejà été fait (mise en place d'un scheduler modulaire, mise en place d'un autre scheduler facultatif, changement des threads de M:N en 1:1, mise en place de nouveaux type de lock, etc ...).

      Concernant OpenBSD, ils sont encore au big lock et il n'y a pas actuellement de mouvement d'envergure pour changer cet état de fait.

      DragonflyBSD a une approche différente (sujet du fork originel). Leur proposition est relativement bien documenté sur leur site web.
      • [^] # Re: et les autres OS ?

        Posté par (page perso) . Évalué à 7.

        >>> Concernant OpenBSD, ils sont encore au big lock et il n'y a pas actuellement de mouvement d'envergure pour changer cet état de fait.

        Leur but est différent puisqu'ils ne cherchent pas la performance à tous prix mais la sécurité, la robustesse et la simplicité.
        Passer au fine grained locking risquerait de déstabiliser le système pour un bon moment et ils estiment que cela n'en vaut pas la peine.
        • [^] # Re: et les autres OS ?

          Posté par . Évalué à 4.

          Tu as une source d'information fiable à ce sujet ?
          • [^] # Re: et les autres OS ?

            Posté par (page perso) . Évalué à 5.

            Interview géante des développeurs OpenBSD suite à la sortie de la version 3.6 : http://www.onlamp.com/lpt/a/5302
            Le journaliste pose la question de savoir quelle technique a été choisie pour le support SMP et Niklas Hallqvist réponds la chose suivante :

            FB: What techniques have you chosen?

            Niklas Hallqvist: Biglock. That means that while a process is executing inside the kernel, no other process gets access to it; instead they will spin until the first process leaves it. This is a bit crude, since some applications won't benefit at all from this kind of multiprocessing. However, most do, especially if things are set up with multiprocessing in mind.
            The reason we have chosen biglock is that it is really simple, and simplicity is a prime objective if security is considered. Fine-grained locking is much harder to do completely right, and things like starvation and deadlocks are much more common. We are just too conservative to risk this.
            • [^] # Re: et les autres OS ?

              Posté par (page perso) . Évalué à 5.

              J'ai l'impression que ca change un peu. Voir http://openbsd.org/plus.html

              - Make PowerPC SMP machines not grab biglock for syscalls marked SY_NOLOCK.
              [...]
              - Make i386 MP kernels not grab biglock for syscalls marked SY_NOLOCK.
              [...]
              - For amd64 and sparc64, do not grab kernel biglock for syscalls marked SY_NOLOCK.
              • [^] # Re: et les autres OS ?

                Posté par (page perso) . Évalué à 7.

                Non, ça c'est de la correction de bug : des BKL étaient appliqués même quand c'était explicité qu'il ne fallait pas.

                ⚓ À g'Auch TOUTE! http://agauch.online.fr

            • [^] # Re: et les autres OS ?

              Posté par . Évalué à 3.

              C'est pas pour te contredire, mais 3.6 ca date de.... 2004 :)

              Depuis pas mal de choses ont changé (en particulier le scheduler), et rien ne dit que ca ne sera jamais envisagé :)
              • [^] # Re: et les autres OS ?

                Posté par (page perso) . Évalué à 5.

                >>> Depuis pas mal de choses ont changé

                Mais pour le BKL je ne crois pas avoir vu passer de gros efforts pour l'enlever.

                >>> rien ne dit que ca ne sera jamais envisagé

                Bien entendu ils peuvent changer d'avis. Faut voir quand même que c'est un boulot immense et très casse-gueule. Si on se réfère à FreeBSD ils ont lancé un effort très déterminé pour supprimer le BKL (le projet SMPng) lors de la branche 5.x (5.0, 5.1, 5.2, 5.3, 5.4). Le travail a continué tout au long de la branche 6.x (6.0, 6.1, 6.2, 6.3) et maintenant qu'on en est à la branche 7.0 le boulot n'est pas encore fini.
                Certes, comme Linux, le code important pour les performances est BKL-free mais il reste encore des appels disséminés dans le reste du code. Si je regarde la dépêche de Bapt à l'occasion de la sortie du 7.0 il est écrit : Poursuite de la suppression du « verrou géant » (aka "Giant Lock"). La majorité des composants importants sont désormais libres de "Giant Lock".
                Si on parle de "la majorité" c'est bien l'indication qu'il en reste.

                C'est dont un travail gigantesque et OpenBSD ne l'a pas encore vraiment commencé. A mon avis ils ont d'ailleurs parfaitement raison car leur créneau n'est pas la performances à tout prix. En gardant le BKL leur code reste simple et facilement auditable et c'est un gros plus quand on se concentre sur la sécurité.
                • [^] # Re: et les autres OS ?

                  Posté par . Évalué à 3.

                  De toutes façons le noyau d'OpenBSD est mono-threadé.
                  Ils auraient donc d'autres chantiers à abattre avant que l'élimination du BKL ait un réel intérêt.

                  Cela dit, étant donné que NetBSD bosse activement sur le sujet, ce sera beaucoup moins difficile pour OpenBSD de s'y mettre, le jour où ça leur chantera (plus facile que ça ne l'a été pour Linux ou FreeBSD, par exemple).
      • [^] # Re: et les autres OS ?

        Posté par . Évalué à 3.

        [[DragonflyBSD a une approche différente (sujet du fork originel). Leur proposition est relativement bien documenté sur leur site web.]]

        Pour info, le but de DragonflyBSD a changé, au départ c'était effectivement d'utiliser une autre approche pour le SMP, maintenant le centre d'interet sont les clusters..
        Donc coté monté en charge en SMP, FreeBSD est beaucoup plus performant que DragonflyBSD..
      • [^] # Re: et les autres OS ?

        Posté par . Évalué à 3.

        ok, merci de ces infos. Et chez windows, AIX ou autres systèmes, quelqu'un sait comment cela se passe, ou si c'est géré mieux ou pas ?

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: et les autres OS ?

          Posté par . Évalué à 7.

          Windows (lignee NT, les autres je sais pas) n'a jamais eu de "Big Lock" qui limitait a un thread/processus dans le noyau a la fois. Il y a plusieurs locks a l'interieur du noyau protegeant differentes structures, mais il n'y a pas un gros lock central qui bloque tout et un effort a ete fait pour parralleliser ce genre de choses tant que possibles(queues par CPU, etc...).

          Maintenant, en ce qui concerne Linux, c'etait le cas avant, mais j'ai de gros doutes quand au fait qu'il y ait encore aujourd'hui un lock enorme de ce genre, qui ne permet qu'a un thread/processus d'entrer dans le noyau, j'imagines plutot qu'il y a plusieurs locks dans le noyau a differents endroits(sur des sections plus ou moins grandes du noyau), dont un particulierement gros et qu'ils veulent les rendre plus fins, ou les prendre moins frequemment. Quoique ce que dit Molnar quand a l'auto-release du BLK me semble bien etrange, et j'ai donc peut-etre bien rate un episode.
  • # Et les micro noyaux type HURD ?

    Posté par . Évalué à 7.

    Je suis peut-être à côté de la plaque mais n'arrive-t-on pas là aux limites intrinsèques des OS monolithiques comme Linux ? La solution n'est-elle pas dans la conception même de l'OS ? Des micro noyaux type HURD ne gèrent-il pas mieux cette problèmatique ?
    • [^] # Re: Et les micro noyaux type HURD ?

      Posté par (page perso) . Évalué à 6.

      La conception du kernel Linux n'est pas - à mon avis - un frein pour ce changement. Le problème se poserait plus dans la méthode à utiliser pour faire ce changement.

      Ca me rappelle des vieilles discussions sur le même thème où les gens confondent la notion de programmation orienté objet avec la notion de langage objet. En gros, c'est pas parce que tu utilises un langage non objet que tu ne peux pas faire de langage objet. Mais il faut néanmoins noter que le fait d'utiliser un langage objet, ça va t'aider à écrire ton programme.

      Dans le cas d'un micro kernel, il doit être effectivement plus simple de faire l'implémentation de petits verrous mais je ne m'avancerais pas trop sur la façon de le faire. On parle ici de procédure technique très très avancé et mes connaissances ne me permettent pas d'en dire beaucoup plus :)
      • [^] # Re: Et les micro noyaux type HURD ?

        Posté par . Évalué à 1.

        Mais il faut néanmoins noter que le fait d'utiliser un langage objet, ça va t'aider à écrire ton programme.
        Mais cela se paye dans la pile logicielle au niveau du compilateur. Dans le cas du C++ par exemple, la complexité du compilateur est délirante par rapport au compilateur C. Et la décoration des symbols au niveau des modules est... bref...
        Il faudrait que le codeurs considèrent plus souvent l'ensemble de la pile logicielle et non uniquement leur programme/module pour faire leurs choix. On a déjà le kernel et la toolchain qui sont très compliqués alors si on peut éviter d'en rajouter...
        • [^] # Re: Et les micro noyaux type HURD ?

          Posté par (page perso) . Évalué à 3.

          Oui mais il faut également mettre dans la balance le fait que tout le monde ne sait pas forcément faire de l'objet en C et que tout le monde n'a pas suffisamment de bagage pour bien coder en C.

          Si tu pars en te disant qu'écrire en C sera plus performant qu'en C++ mais que ton code est de moins bonne qualité qu'en C++, tu perdras le bénéfice d'utilisation d'un langage plus "rapide". En effet, le surcoût de l'utilisation d'un langage intermédiaire est négligeable au vu des bénéfices. Dans le cas des dev du kernel, je pense qu'on a pas à se faire ce genre de soucis mais tu n'as pas toujours des gens aussi talentueux.

          Tu peux même pousser la réflexion plus loin et te posant la question du temps que tu vas passer sur ton projet. Il est par exemple plus rapide de coder un site Web en PHP qu'en C parce que le langage est fait pour ça.

          Tout dépendra du temps qu'il te faut. En caricaturant, ça donne un truc de ce genre :
          - un développement rapide mais une exécution lente
          - un développement lent mais une exécution rapide.

          Tout dépendra du temps que tu auras pour faire ton projet et si le coût le justifie. Il ne faut pas oublier que le kernel Linux utilise du shell pour démarrer dans la plupart des distributions :)
          • [^] # Re: Et les micro noyaux type HURD ?

            Posté par . Évalué à 5.

            >Il ne faut pas oublier que le kernel Linux utilise du shell pour démarrer dans la plupart des distributions :)

            Ce qui donne en final que BeOS sur un Celeron333 mettait moins de 20s pour demarrer (hors BIOS, depuis GRUB jusqu'a l'IHM utilisable), mais une distribution Linux peut mettre facilement plus de 3 fois le temps sur du matériel bien plus puissant.

            Ca n'a pas de rapport avec la choucroute juste pour montrer que si un point n'a "pas d'importance" comme le temps de démarrage, au final ça peut devenir du n'importe quoi.
            • [^] # Re: Et les micro noyaux type HURD ?

              Posté par . Évalué à 1.

              Sachant que ce qui est lent sous linux, c'est le démarrage des services et la découverte des périphériques, je pense que BeOS n'avait pas beaucoup de service activé par défaut.

              Coté driver, il devait être limité mais si j'ai bien compris son architecture micro noyau lui permettait de réutiliser les drivers linux. Donc, la phase d'init est la même.

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

              • [^] # Re: Et les micro noyaux type HURD ?

                Posté par . Évalué à 2.

                >Sachant que ce qui est lent sous linux, c'est le démarrage des services et la découverte des périphériques

                Pas uniquement: KDE tout seul peut mettre plus de temps a demarrer que BeOS n'en mettait pour booter au total (kernel boot+IHM).

                >je pense que BeOS n'avait pas beaucoup de service activé par défaut.

                Ce qui est une bonne conception, ne serait-ce que du point de vue sécurité..

                >Coté driver, il devait être limité

                Le matériel compatible était limité oui, mais en quoi cela explique un boot plus lent ou plus rapide?

                >mais si j'ai bien compris son architecture micro noyau lui permettait de réutiliser les drivers linux. Donc, la phase d'init est la même.

                Non, je ne pense pas que BeOS réutilisait les drivers Linux, ne serait-ce que d'un point de vue licence cela ne passerait pas..
                • [^] # Re: Et les micro noyaux type HURD ?

                  Posté par . Évalué à 6.

                  Pas uniquement: KDE tout seul peut mettre plus de temps a demarrer que BeOS n'en mettait pour booter au total (kernel boot+IHM).

                  Mais l'ihm de BeOS ne faisait pas ce que fait KDE. Comparre avec icewm ou windows maker dans ce cas.

                  Ce qui est une bonne conception, ne serait-ce que du point de vue sécurité..

                  Donc, tu ne compares pas à fonctionnalité identique.


                  Le matériel compatible était limité oui, mais en quoi cela explique un boot plus lent ou plus rapide?


                  Beaucoup moins de "probe" à tester pour identifier tous le matériel. C'est la majeur partie du temps de boot du kernel lui-même.

                  Non, je ne pense pas que BeOS réutilisait les drivers Linux, ne serait-ce que d'un point de vue licence cela ne passerait pas..

                  De mémoire, il avait fait un tour de passe-passe très limite avec un serveur de drivers qui était en open-source qu'utilisais le reste du noyau.

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

                • [^] # Re: Et les micro noyaux type HURD ?

                  Posté par . Évalué à 1.

                  > Pas uniquement: KDE tout seul peut mettre plus de temps a demarrer que BeOS n'en mettait pour booter au total (kernel boot+IHM).

                  Le boot le plus rapide jusqu'à l'ihm pour moi ?
                  Simple : Windows 3.1.
                  Diablement rapide (outils norton compris).
                  Mais il ne me manque pas.
                  • [^] # Re: Et les micro noyaux type HURD ?

                    Posté par . Évalué à 6.

                    Bof, tu sous entends qu'on ne peut pas comparer BeOS et un desktop sous Linux parce qu'ils seraient trop différent?

                    Je ne suis pas d'accord: Interface graphique évoluée (mis a part les effets 3D récent), protection mémoire, scheduler prémptif, etc BeOS était tres similaire a un desktop Unix (sauf qu'il avait une réactivité bien supérieure)..


                    Par contre, il y a plusieurs énormes différence entre Windows3.1 et des systèmes d'exploitations moderne (BeOS, Linux et autres):
                    -scheduler préemptif vs coopératif.
                    -protection mémoire.
                    -...
                    • [^] # Re: Et les micro noyaux type HURD ?

                      Posté par . Évalué à 1.

                      > Bof, tu sous entends qu'on ne peut pas comparer BeOS et un desktop sous Linux parce qu'ils seraient trop différent?

                      Ce n'est pas ce que j'ai voulu dire.

                      Ce qui m'énerve c'est qu'on donne trop d'importance au temps de boot.
                      J'en est rien à foutre que mon PC boote en 10 ou 30 ou 120 secondes.
                      • [^] # Re: Et les micro noyaux type HURD ?

                        Posté par (page perso) . Évalué à 3.

                        Et bien moi, j'en ai quelque chose à faire ...
                        et je trouve que c'est trop lent (c'est peut être aussi parce que je rajoute des couches: booter grub en mode BIOS sur de l'EFI ça prend du temps)
          • [^] # Re: Et les micro noyaux type HURD ?

            Posté par . Évalué à 9.

            J'aurai presque ton avis, mais dans le cas du C/C++ la question est quand même un peu biaisée, le C étant un langage simple mais permissif, avec potentiellement plein de pièges, le C++ rajoutant une couche objet, censée faciliter la vie du programmeur, mais pas seulement et ajoutant son lot de complexité lui aussi (template, meta programmation utilisée intensivement dans les bibliothèques standards, trucs plutôt redondant par rapport au C, gestion mémoire à la main/par des smart pointer/par un gc ...) et tout en permettant toutes les "craderies" du C.

            Le C++ permet le meilleur ... comme le pire. Bref c'est pas forcément le bon langage à mettre dans les mains d'un programmeur inexpérimenté, qui peut se retrouver perdu dans les méandres de possibilité, faire les mauvais choix parce qu'il connait trop ou pas assez du C++ ...
        • [^] # Re: Et les micro noyaux type HURD ?

          Posté par . Évalué à 6.

          C'est pas un soucis, ça, en gros tu déplace la complexité de "n'importe quel programmeur" sur les programmeurs du compilateur et sur les concepteurs du langage seulement.

          À priori un gain pour le plus grand nombre ce type de démarche si tu arrives à quelque chose de bien sur ton compilateur et ton langage. En plus ça permet de passer à autre chose derrière, style ingénierie des modèles, et d'explorer d'autres voies qui vont (peut être) encore faciliter la vie de tous.
        • [^] # Re: Et les micro noyaux type HURD ?

          Posté par (page perso) . Évalué à 3.

          Dans le cas du C++ par exemple, la complexité du compilateur est délirante par rapport au compilateur C.

          Le langage D est un bon exemple de langage orienté objet où le compilateur reste relativement simple. C'est d'ailleurs un des objectifs du langage. Et ça ne l'empêche pas de proposer des templates, et autres fonctionnalités annexes.
          • [^] # Re: Et les micro noyaux type HURD ?

            Posté par . Évalué à 5.

            Le problème du C++ ce ne sont pas les fonctionnalités Objet de haut niveau, mais plutôt qu'il faut absolument continuer de supporter toutes les fonctionnalités de bas niveau du C et (essayer de) s'arranger pour que cela s'agence correctement pour les programmeurs pervers qui s'amusent à mélanger les deux dans un même projet.
    • [^] # Re: Et les micro noyaux type HURD ?

      Posté par . Évalué à 4.

      Des micro noyaux type HURD ne gèrent-il pas mieux cette problèmatique
      Tu as vu les performances des micros noyau de type HURD ?
      En effet dans ce type de kernel l'échange de message des différents drivers/module "userspace" à un coup : il faut faire un passage user/kernel puis kernel/user.

      Le problème ici vient plutot du fait que Linux n'a pas été à l'origine conçu pour des platformes SMP. D'ou certain pb de resource partagée qui ont du être comblé par un vérou global (pour pouvoir faire tourner facilement l'existant).
      • [^] # Re: Et les micro noyaux type HURD ?

        Posté par . Évalué à 6.

        Les performances des micros noyaux?
        Il faut arrêter, on n'est plus au temps de Minix 1...
        Il y a eu _beaucoup_ de progrès, la diminution de performance est négligeable.

        En ce qui concerne les ressources partagées, cela me rappele un poste de Linus, qui casse le mythe de la simplicité d'un micro-noyau par rapport à un noyau monolithique:

        The fundamental result of access space separation is that
        you can't share data structures. That means that you can't
        share locking, it means that you must copy any shared data,
        and that in turn means that you have a much harder time
        handling coherency. All your algorithms basically end up
        being distributed algorithms.
        And anybody who tells you that distributed algorithms
        are "simpler" is just so full of sh*t that it's not even
        funny.
        Microkernels are much harder to write and maintain
        exactly because of this issue. You can do simple
        things easily - and in particular, you can do things where
        the information only passes in one direction quite easily,
        but anythign else is much much harder, because there is
        no "shared state" (by design). And in the absense of shared
        state, you have a hell of a lot of problems trying to make
        any decision that spans more than one entity in the
        system.

        Le reste ici : http://www.realworldtech.com/forums/index.cfm?action=detail&(...)

        Sinon, il y a tout plein de méchanisme de synchronisation granulaires dans le noyau : spinlock_t, spinlock_bh, rw_lock_t, ...
        Le problème c'est qu'on ne peut pas employer n'importe quoi n'importe où (interruption, softirq, etc).
        • [^] # Re: Et les micro noyaux type HURD ?

          Posté par (page perso) . Évalué à 4.

          > cela me rappele un poste de Linus,

          Ah ben voilà, je me disais bien qu'il y avait un truc. Linus n'est pas techniquement exceptionnel, c'est juste qu'il travaille sur des postes très en avance techniquement.

          Mon poste à moi il n'est pas capable d'une telle reflexion sur le travail que je réalise. En général il se contente d'un "Core Dump" ou "Parse Error" en réponse à ce que je fais.

          (attention, Humour inside, même s'il est mauvais)
        • [^] # Re: Et les micro noyaux type HURD ?

          Posté par . Évalué à 2.

          Sinon, il y a tout plein de méchanisme de synchronisation granulaires dans le noyau : spinlock_t, spinlock_bh, rw_lock_t, ...
          Le problème c'est qu'on ne peut pas employer n'importe quoi n'importe où (interruption, softirq, etc).


          En effet, le kernel est un terrain nettement moins confortable que le user space. Pourtant, il y a des efforts faits pour imiter certains services du user space en kernel space (par exemple, les strings, les formats du printk, les lists etc) afin de faire le moins peur possible à ceux qui font leurs premières armes dans le kernel.
  • # bkl

    Posté par . Évalué à 2.

    [cite]Pour rebondir sur le sujet, comment s'en sortent les autres systèmes d'exploitation par rapport à ce problème ? Freebsd a été brièvement évoqué, qu'en est-il de windows, solaris, mac os x par exemple ?[/cite]

    FreeBsd utilise les mutex pour diviser le BKL en de nombreux verrous fins.
    Dragonfly a été crée en raison de cetteimplémentation et utilise pour sa part le Light weight kernel threading. (LWKT)
  • # Merci pour l'article

    Posté par (page perso) . Évalué à 9.

    J'aime beaucoup la théorie informatique, elle me fascine littéralement. La capacité d'abstraction, et de raisonnement sur des mécanismes proches de l'intelligence, de ceux qui la maîtrise me sidère.
    Mais je ne suis pas du tout informaticien de formation. Comme je la parcoure en dilettante, je suis trop souvent trop vite largué, et j'abandonne alors vite la lecture, vaguement frustré de n'avoir pas su suivre des formations scientifiques/informatiques.
    Mais tes articles sont toujours superbes, et me redonnent à chaque fois du plaisir et du réconfort. À la fois pointus et clairs, parfaitement vulgarisés, ils me laissent à chaque fois plus cultivé et avec une meilleure compréhension des outils que j'utilise.
    Donc bravo et merci.
    • [^] # Re: Merci pour l'article

      Posté par (page perso) . Évalué à 7.

      Moi je trouve pas que la dépêche parle de théorie, mais plutôt de pratique (ce qui est fait dans le noyaux Linux)

      Pour moi, la théorie de l'informatique c'est plutôt la Logique, la Calculabilité, la Vérification, et les autres articles de cette pages http://fr.wikipedia.org/wiki/Catégorie:Informatique_théorique
      Bref, tous les trucs qu'on apprends à l'unif uniquement parce qu'on est bien obligé :-)

      Mais il est vrai que il est difficile de faire un article technique sur le fonctionnement du noyaux tout en restant abordable. Et je trouve que cette dépêche est plutôt bien faite dans ce genre. Et quand il y a des trucs que tu ne trouve pas clair, tu peux toujours laisser un commentaire pour demander un éclaircissement... c'est ça DLFP

Suivre le flux des commentaires

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