Grâce au multiplexage d'espace d'addressage (expliqué en détail dans les docs L4), justement, on peut faire de l'IPC sans réel changement de contexte (sans TLB flush par exemple).
Pour de l'IPC entre deux processus différents, oui, on est obligé de passer par le noyau. Par contre, le code exécuté dans le noyau pour transmettre l'IPC est si court et si simple, qu'il s'exécute très rapidement, et surtout sans polluer les lignes de cache. Le coût total d'un RPC L4 est donc inférieur à celui d'un appel système sur Linux.
De plus, dés qu'on veut un peu plus de fiabilité, de tolérance de panne et de souplesse, on ne met plus la totalité du code dans le noyau (comme le serveur X, par exemple, qui est en user-space). Donc là, on se retrouve à faire de l'IPC entre le client et X, avec un noyau qui n'est pas du tout prévu pour, et donc on a une perte de performances beaucoup plus importante. La même chose s'applique, par exemple, à une compilation en -pipe, ...
Tout ça pour dire que aujourd'hui je pense qu'aucun système à micro-noyau n'est aussi performant qu'un système "monolithique".
Je ne l'ai jamais nié. L4 existe, est extrêment rapide, mais il n'existe pas encore de système complet basé sur L4 aussi versatile qu'un GNU/Linux (il y'a bien des OS basés sur L4, mais uniquement pour des domaines très pointus et précis pour l'instant).
Quant aux modules, ça n'a absolument rien à voir avec ce que peut faire un système à base de micro-noyau.
[^] # 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.
Grâce au multiplexage d'espace d'addressage (expliqué en détail dans les docs L4), justement, on peut faire de l'IPC sans réel changement de contexte (sans TLB flush par exemple).
Pour de l'IPC entre deux processus différents, oui, on est obligé de passer par le noyau. Par contre, le code exécuté dans le noyau pour transmettre l'IPC est si court et si simple, qu'il s'exécute très rapidement, et surtout sans polluer les lignes de cache. Le coût total d'un RPC L4 est donc inférieur à celui d'un appel système sur Linux.
De plus, dés qu'on veut un peu plus de fiabilité, de tolérance de panne et de souplesse, on ne met plus la totalité du code dans le noyau (comme le serveur X, par exemple, qui est en user-space). Donc là, on se retrouve à faire de l'IPC entre le client et X, avec un noyau qui n'est pas du tout prévu pour, et donc on a une perte de performances beaucoup plus importante. La même chose s'applique, par exemple, à une compilation en -pipe, ...
Tout ça pour dire que aujourd'hui je pense qu'aucun système à micro-noyau n'est aussi performant qu'un système "monolithique".
Je ne l'ai jamais nié. L4 existe, est extrêment rapide, mais il n'existe pas encore de système complet basé sur L4 aussi versatile qu'un GNU/Linux (il y'a bien des OS basés sur L4, mais uniquement pour des domaines très pointus et précis pour l'instant).
Quant aux modules, ça n'a absolument rien à voir avec ce que peut faire un système à base de micro-noyau.