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.
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.
Aller plus loin
- Article de KernelTrap (21 clics)
- L'annonce sur Slashdot (30 clics)
# patrick_g, sors de ce corps !
Posté par nonas . Évalué à 9.
[^] # Re: patrick_g, sors de ce corps !
Posté par B16F4RV4RD1N . Évalué à 10.
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
[^] # Re: patrick_g, sors de ce corps !
Posté par chl (site web personnel) . Évalué à 10.
Pas besoin de tags cloud ni de Web 2.0 pour cela, il suffit de cliquer ici:
http://linuxfr.org/~patrick_g/news.html
[^] # Re: patrick_g, sors de ce corps !
Posté par Sytoka Modon (site web personnel) . Évalué à -1.
[^] # Re: patrick_g, sors de ce corps !
Posté par BAud (site web personnel) . Évalué à 7.
[^] # Re: patrick_g, sors de ce corps !
Posté par tfeserver tfe (site web personnel) . Évalué à 1.
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.
Ecris un patch!
:x
[^] # Re: patrick_g, sors de ce corps !
Posté par NickNolte . Évalué à 1.
Ecris un patch!Ou utilisez un vrai CMS qui intégre déjà un tas de trucs qu'on a pas besoin de reécrire?
[^] # Re: patrick_g, sors de ce corps !
Posté par oops (site web personnel) . Évalué à 4.
Tu as 4 machines à donner ?
[^] # Re: patrick_g, sors de ce corps !
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
# Bravo
Posté par Kyle_the_hacker . Évalué à 10.
# Un petit correctif
Posté par reno . Évalué à 7.
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!
[^] # Re: Un petit correctif
Posté par patrick_g (site web personnel) . Évalué à 9.
Argh...voilà ce que c'est que de réorganiser la liste sans penser à updater la phrase qui vient après.
[^] # Re: Un petit correctif
Posté par patrick_g (site web personnel) . Évalué à 4.
"Ingo Molnar avait choisi la première solution mais Linus a opté pour la seconde".
Par la phrase :
"Ingo Molnar avait choisi la seconde solution mais Linus a opté pour la troisième".
[^] # Re: Un petit correctif
Posté par patrick_g (site web personnel) . Évalué à 4.
[^] # Re: Un petit correctif
Posté par tuXico . Évalué à 3.
Mias ça ne change rien au fond de cet excellent post :)
[^] # Re: Un petit correctif
Posté par François B. . Évalué à 2.
[^] # Re: Un petit correctif
Posté par IsNotGood . Évalué à 6.
[^] # Re: Un petit correctif
Posté par mickabouille . Évalué à 1.
>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
C'est pas Alan Cox plutôt?
[^] # Re: Un petit correctif
Posté par patrick_g (site web personnel) . Évalué à 6.
[^] # Re: Un petit correctif
Posté par mickabouille . Évalué à 1.
[^] # Re: Un petit correctif
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
[^] # Pas tout compris
Posté par Spack . Évalué à 2.
Et plus loin :
J'ai pas trop compris cette partie, il choisit de revenir au BKL pour l'enlever???
[^] # Re: Pas tout compris
Posté par patrick_g (site web personnel) . Évalué à 7.
Il veut remettre le vieux BKL non préemptible pour que ça emmerde les gens. Ainsi ils seront motivés pour se bouger la couenne et bosser sur la véritable suppression du BKL dans le noyau.
# Et CONFIG_PREEMPT_RT ?
Posté par pleiades . Évalué à 9.
http://kerneltrap.org/mailarchive/linux-kernel/2008/5/14/1821774
pl.
# Chapeau !!
Posté par nazcafan . Évalué à 10.
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 Éric (site web personnel) . Évalué à 4.
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 patrick_g (site web personnel) . Évalué à 8.
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 Guillaume Knispel . Évalué à 5.
[^] # Re: Et en attendant ?
Posté par ribwund . Évalué à 6.
Il se passe encore environ 1 mois avant la sortie du kernel.
# Sémaphore et mutex
Posté par IsNotGood . Évalué à 3.
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 reno . Évalué à 5.
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 patrick_g (site web personnel) . Évalué à 2.
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 IsNotGood . Évalué à -1.
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 IsNotGood . Évalué à 5.
- "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 M . Évalué à 2.
Les sémaphore kernel restant vont plutot etre remplacé par des waitqueue IIRC.
[^] # Re: Sémaphore et mutex
Posté par IsNotGood . Évalué à 3.
???
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.
[^] # Re: Sémaphore et mutex
Posté par Jean B . Évalué à 7.
semaphore kernel != semaphores noyaualors que
kernel === noyauIl y a un truc que je suis pas là
[^] # Re: Sémaphore et mutex
Posté par BAud (site web personnel) . Évalué à 7.
# Vers ou ?
Posté par eastwind☯ . Évalué à 3.
[^] # Re: Vers ou ?
Posté par Georges Dubus (site web personnel) . Évalué à 8.
http://fr.wikipedia.org/wiki/Direct_Rendering_Manager
# et les autres OS ?
Posté par tomachaka . Évalué à 7.
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 zul (site web personnel) . Évalué à 6.
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 patrick_g (site web personnel) . Évalué à 7.
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 gaston . Évalué à 4.
[^] # Re: et les autres OS ?
Posté par patrick_g (site web personnel) . Évalué à 5.
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 TeXitoi (site web personnel) . Évalué à 5.
- 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 ʭ ☯ . Évalué à 7.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: et les autres OS ?
Posté par gaston . Évalué à 3.
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 patrick_g (site web personnel) . Évalué à 5.
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 herodiade . Évalué à 3.
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 reno . Évalué à 3.
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 B16F4RV4RD1N . Évalué à 3.
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 pasBill pasGates . Évalué à 7.
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 topisto . Évalué à 7.
[^] # Re: Et les micro noyaux type HURD ?
Posté par YvanLeTerrible . Évalué à 6.
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 GPL . Évalué à 1.
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 YvanLeTerrible . Évalué à 3.
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 reno . Évalué à 5.
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 Nicolas Boulay (site web personnel) . Évalué à 1.
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 reno . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 6.
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 IsNotGood . Évalué à 1.
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 reno . Évalué à 6.
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 IsNotGood . Évalué à 1.
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 Mildred (site web personnel) . Évalué à 3.
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 Thomas Douillard . Évalué à 9.
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 Thomas Douillard . Évalué à 6.
À 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 e-t172 (site web personnel) . Évalué à 3.
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 wismerhill . Évalué à 5.
[^] # Re: Et les micro noyaux type HURD ?
Posté par Mildred (site web personnel) . Évalué à 3.
[^] # Re: Et les micro noyaux type HURD ?
Posté par Étienne . Évalué à 2.
Ou comme du Java
[^] # Re: Et les micro noyaux type HURD ?
Posté par imalip . Évalué à 6.
Un collegue.
[^] # Re: Et les micro noyaux type HURD ?
Posté par IsNotGood . Évalué à 2.
C'est un language (très) compliqué, mais "surprenant" (et parfois ugly).
[^] # Re: Et les micro noyaux type HURD ?
Posté par M . Évalué à 4.
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 neologix . Évalué à 6.
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 Éric (site web personnel) . Évalué à 4.
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 GPL . Évalué à 2.
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 Edgar Smith . Évalué à 2.
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 Zorro (site web personnel) . Évalué à 9.
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 Gof (site web personnel) . Évalué à 7.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.