Donc, le micro-noyau a beau être le plus rapide, ça ne change rien, c'est AMHA un problème d'architecture.
Houlalala, depuis quand les micro noyaux sont plus rapides ?
Comment ça je n'ai pas lu les doces citées plus haut ? Si, si.
Je vais sur le site en question.
Je lis "The Performance of µ-Kernel-Based Systems" ( http://l4ka.org/publications/files/ukernel-performance.pdf(...) ).
Je vois page 6 et 7 : résultats.
Tout va plus lentement sur L4 que sur Linux (sans exception).
Maintenant pour les sceptiques j'ajouterai que les micro-noyaux ne peuvent pas aller plus vite que les systèmes monolithiques, simplement parce qu'un système monolithique utilise moins de protections mémoire qu'un système micro-noyau.
En plus, on a à faire face au problème récurrent des micro-noyaux : toutes les communications doivent se faire par passage de messages d'un serveur à l'autre. Donc si j'utilise mon api noyau préférée, mes données doivent traverser l'espace d'adressage de chacun des serveurs avant d'arriver au matériel, pareil dans l'autre sens. Même si ces communications se font par un segment de mémoire partagée, cela a un coût (imaginez si ce sont des textures ou des commandes OpenGL qui doivent transiter vers la carte vidéo, l'appli va être lente si elles n'arrivent pas rapidement). Sur un noyau monolithique, un appel et le noyau a récupéré toutes les données dans son espace d'adressage et ca va direct au matos.
Evidemment, un noyau monolithique est plus difficile à mettre au point (pas de droit à l'erreur, sinon on plante tout le noyau), mais de toute manière on ne peut pas se permettre d'avoir un bout du noyau qui plante, même si ce n'est q'un serveur de micro noyau (je vois mal les développeurs écrire un serveur de filesystem qui plante toutes les 5 min mais "c'est pas grave on peut le redémarrer le reste plante pas"). C'est le même problème avec les debuggeurs du noyau : il faut faire du bon code ou rien du tout. On ne fait pas marcher un programme (à plus forte raison le noyau, partie critique d'un système) en bidouillant avec un debuggeur.
Et en utilisant le système des modules (inspiré des micro noyau), Linus y a gagné en flexibilité, sans y perdre en rapidité. A mon avis son approche est la bonne, et elle convient au plus grand nombre : ajout/suppression dynamique de modules, dépendances entre ceux-ci etc...
A propos de la sécurité, il existe à l'heure actuelle des patchs comme grsecurity qui font plus que leur travail, avec les ACL par exemple.
Donc je ne vois pas de raison technique de passer sur un micro noyau. Par contre je vois l'avantage de rester sur noyau monolithique. L'important est de toute manière que les logiciels open source doivent être portables sur tous types de noyaux et à terme on pourrait imaginer que le choix du noyau devienne une question de préférences personnelles !
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Houlalala, depuis quand les micro noyaux sont plus rapides ?
Comment ça je n'ai pas lu les doces citées plus haut ? Si, si.
Je vais sur le site en question.
Je lis "The Performance of µ-Kernel-Based Systems" ( http://l4ka.org/publications/files/ukernel-performance.pdf(...) ).
Je vois page 6 et 7 : résultats.
Tout va plus lentement sur L4 que sur Linux (sans exception).
Oui tu as raison c'est un document un peu vieux (1997).
Je prends "Performance of Address-Space Multiplexing on the Pentium" ( http://l4ka.org/publications/files/smallspaces-tr-2002-1.pdf(...) ).
Page 6 : même résultat : linux va plus vite que L4.
Maintenant pour les sceptiques j'ajouterai que les micro-noyaux ne peuvent pas aller plus vite que les systèmes monolithiques, simplement parce qu'un système monolithique utilise moins de protections mémoire qu'un système micro-noyau.
En plus, on a à faire face au problème récurrent des micro-noyaux : toutes les communications doivent se faire par passage de messages d'un serveur à l'autre. Donc si j'utilise mon api noyau préférée, mes données doivent traverser l'espace d'adressage de chacun des serveurs avant d'arriver au matériel, pareil dans l'autre sens. Même si ces communications se font par un segment de mémoire partagée, cela a un coût (imaginez si ce sont des textures ou des commandes OpenGL qui doivent transiter vers la carte vidéo, l'appli va être lente si elles n'arrivent pas rapidement). Sur un noyau monolithique, un appel et le noyau a récupéré toutes les données dans son espace d'adressage et ca va direct au matos.
Evidemment, un noyau monolithique est plus difficile à mettre au point (pas de droit à l'erreur, sinon on plante tout le noyau), mais de toute manière on ne peut pas se permettre d'avoir un bout du noyau qui plante, même si ce n'est q'un serveur de micro noyau (je vois mal les développeurs écrire un serveur de filesystem qui plante toutes les 5 min mais "c'est pas grave on peut le redémarrer le reste plante pas"). C'est le même problème avec les debuggeurs du noyau : il faut faire du bon code ou rien du tout. On ne fait pas marcher un programme (à plus forte raison le noyau, partie critique d'un système) en bidouillant avec un debuggeur.
Et en utilisant le système des modules (inspiré des micro noyau), Linus y a gagné en flexibilité, sans y perdre en rapidité. A mon avis son approche est la bonne, et elle convient au plus grand nombre : ajout/suppression dynamique de modules, dépendances entre ceux-ci etc...
A propos de la sécurité, il existe à l'heure actuelle des patchs comme grsecurity qui font plus que leur travail, avec les ACL par exemple.
Donc je ne vois pas de raison technique de passer sur un micro noyau. Par contre je vois l'avantage de rester sur noyau monolithique. L'important est de toute manière que les logiciels open source doivent être portables sur tous types de noyaux et à terme on pourrait imaginer que le choix du noyau devienne une question de préférences personnelles !