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.
J'attendais ce contre argument. Mais justement, au début de l'article, l'auteur mesure l'overhead de l4linux à 5%. Et la différence de perf linux/micro noyau est de plus de 5%. Donc...
Ç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 ?
J'ai besoin d'un appel au serveur d'affichage à chaque fois que j'affiche un truc. A comparer au dga, seule méthode qui me permet de jouer des divx sans saccades sur ma machine.
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.
Oui, mais qu'est-ce qui m'empêche d'implanter la même optimisation sur noyau monolithique ?
Tu peux comparer ça à ce qui est présenté dans http://l4ka.org/publications/files/os-protectio(...) ? 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.
Effectivement, on a un avantage au niveau de la securité (que je n'ai pas nié). Mais je préfère la rapidité. Les mechanismes de sécurité de Linux me suffisent largement. Et pour l'instant ce genre de choses j'attends de le voir tourner.
Et il reste sur les processeurs x86 deux niveaux de privilège d'exécution non utilisés qui pourraient être utilisés pour ça.
Voila, merci de m'avoir fait me replonger dans les micro noyaux, ca fait un certain temps que j'y avais pas regardé et ça a l'air d'évoluer en bien.
[^] # 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.
J'attendais ce contre argument. Mais justement, au début de l'article, l'auteur mesure l'overhead de l4linux à 5%. Et la différence de perf linux/micro noyau est de plus de 5%. Donc...
Ç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 ?
J'ai besoin d'un appel au serveur d'affichage à chaque fois que j'affiche un truc. A comparer au dga, seule méthode qui me permet de jouer des divx sans saccades sur ma machine.
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.
Oui, mais qu'est-ce qui m'empêche d'implanter la même optimisation sur noyau monolithique ?
Tu peux comparer ça à ce qui est présenté dans http://l4ka.org/publications/files/os-protectio(...) ? 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.
Effectivement, on a un avantage au niveau de la securité (que je n'ai pas nié). Mais je préfère la rapidité. Les mechanismes de sécurité de Linux me suffisent largement. Et pour l'instant ce genre de choses j'attends de le voir tourner.
Et il reste sur les processeurs x86 deux niveaux de privilège d'exécution non utilisés qui pourraient être utilisés pour ça.
Voila, merci de m'avoir fait me replonger dans les micro noyaux, ca fait un certain temps que j'y avais pas regardé et ça a l'air d'évoluer en bien.