Tout va plus lentement sur L4 que sur Linux (sans exception).
T'as rien compris à l'article. Il compare L4Linux et Linux. Bien évidemment un port de Linux au-dessus de L4 à coup de glue-code est plus lent que Linux en natif. Le but de cet article n'est pas de comparer L4 et Linux (ce qui n'a pas de sens) mais de comparer L4 et Mach dans le cadre de L4Linux et de MkLinux.
De plus le L4Linux testé est basé sur une vieille version de L4 qui est loin d'implémenter toutes les optimisations possibles.
"Performance of Address-Space Multiplexing on the Pentium"
Idem, cet article compare L4Linux et Linux, avec des applications utilisant les sémantiques POSIX. Pas un système à base de L4 utilisant les sémantiques L4 et des programmes utilisant de l'IPC L4.
simplement parce qu'un système monolithique utilise moins de protections mémoire qu'un système micro-noyau.
et ?
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.
Ça et le reste du paragraphe montre que tu n'as rien compris à la philosophie des micro-noyau. Dans un système à base de micro-noyau 'idéal', le serveur d'affichage 'mappe' la mémoire vidéo dans son espace d'addressage à lui; le client qui veut afficher des textures fait un IPC vers le serveur d'affichage en passant les données à placer via des flex-pages (pour prendre la sémantique L4). Le serveur d'affichage fait la copie et rend la main. Coût total: un RPC. Aucune copie superflue. Tu perds quoi, concrètement ?
Prenons un autre exemple: une écriture sur le disque. Sur un noyau monolithique, tu appelles write(), qui copie les données dans le buffer du driver et ensuite les écrit. Sur un système à base de micro-noyau, tu passes tes flex-page contenant les données (donc, juste un IPC faisant un 'grant' sur les pages, aucune copie) au driver, qui 'pin' les pages en mémoire (pour éviter qu'elles ne soient swappées) et démarre le transfert DMA. Total: aucune copie n'a été réalisée.
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.
Tu peux comparer ça à ce qui est présenté dans http://l4ka.org/publications/files/os-protection.pdf(...) ? On joue pas dans la même catégorie là... Avec tous tes ACLs et des patchs grsecurity, login, sshd et *ftpd tournent toujours en root sur ta machine, je te signale.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
T'as rien compris à l'article. Il compare L4Linux et Linux. Bien évidemment un port de Linux au-dessus de L4 à coup de glue-code est plus lent que Linux en natif. Le but de cet article n'est pas de comparer L4 et Linux (ce qui n'a pas de sens) mais de comparer L4 et Mach dans le cadre de L4Linux et de MkLinux.
De plus le L4Linux testé est basé sur une vieille version de L4 qui est loin d'implémenter toutes les optimisations possibles.
"Performance of Address-Space Multiplexing on the Pentium"
Idem, cet article compare L4Linux et Linux, avec des applications utilisant les sémantiques POSIX. Pas un système à base de L4 utilisant les sémantiques L4 et des programmes utilisant de l'IPC L4.
simplement parce qu'un système monolithique utilise moins de protections mémoire qu'un système micro-noyau.
et ?
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.
Ça et le reste du paragraphe montre que tu n'as rien compris à la philosophie des micro-noyau. Dans un système à base de micro-noyau 'idéal', le serveur d'affichage 'mappe' la mémoire vidéo dans son espace d'addressage à lui; le client qui veut afficher des textures fait un IPC vers le serveur d'affichage en passant les données à placer via des flex-pages (pour prendre la sémantique L4). Le serveur d'affichage fait la copie et rend la main. Coût total: un RPC. Aucune copie superflue. Tu perds quoi, concrètement ?
Prenons un autre exemple: une écriture sur le disque. Sur un noyau monolithique, tu appelles write(), qui copie les données dans le buffer du driver et ensuite les écrit. Sur un système à base de micro-noyau, tu passes tes flex-page contenant les données (donc, juste un IPC faisant un 'grant' sur les pages, aucune copie) au driver, qui 'pin' les pages en mémoire (pour éviter qu'elles ne soient swappées) et démarre le transfert DMA. Total: aucune copie n'a été réalisée.
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.
Tu peux comparer ça à ce qui est présenté dans http://l4ka.org/publications/files/os-protection.pdf(...) ? On joue pas dans la même catégorie là... Avec tous tes ACLs et des patchs grsecurity, login, sshd et *ftpd tournent toujours en root sur ta machine, je te signale.