Et la différence de perf linux/micro noyau est de plus de 5%. Donc...
Donc quoi ? Linux n'est pas adapté à être mis en monoserveur au-dessus d'un micro-noyau. C'est un fait, et c'est évident. Mais cela ne permet donc pas de juger des performances possibles pour un système versatile utilisant L4. En revanche, on peut considérer qu'étant donné que même dans ce cas suboptimal, les différences sont assez minimes à l'utilisation, les performances d'un tel système *conçu* pour les µk et tirant parti de L4 (notamment des LIPC, etc.) pourraient être excellentes.
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.
1/ implémenter un protocole pour demander au serveur d'affichage de mapper la mémoire vidéo dans la mémoire de l'appli c'est parfaitement possible
2/ le DGA sous GNU/Linux, il faut avoir les droits roots. Avec un protocole bien conçu, il est possible de faire sur un multi-serveur sans avoir de droit root (juste un token "dga")
Oui, mais qu'est-ce qui m'empêche d'implanter la même optimisation sur noyau monolithique ?
Fais-le, et on verra. Le kernel space et l'user space sont deux espaces distincts. Faire une opération de 'grant' ou de 'map' entre deux programmes en espace utilisateur (le client et le driver) c'est la base de l'IPC de L4, c'est extrêment simple. Permettre au driver de taper directement dans la mémoire de l'application, sachant que le driver fonctionne de manière asynchrone et que l'appel write() peut être non-bloquant est quelque chose de beaucoup plus complexe. Presque infaisable.
Effectivement, on a un avantage au niveau de la securité (que je n'ai pas nié). et un peu avant Donc je ne vois pas de raison technique de passer sur un micro noyau.
Heu... contradiction là ?
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.
[^] # 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.
Donc quoi ? Linux n'est pas adapté à être mis en monoserveur au-dessus d'un micro-noyau. C'est un fait, et c'est évident. Mais cela ne permet donc pas de juger des performances possibles pour un système versatile utilisant L4. En revanche, on peut considérer qu'étant donné que même dans ce cas suboptimal, les différences sont assez minimes à l'utilisation, les performances d'un tel système *conçu* pour les µk et tirant parti de L4 (notamment des LIPC, etc.) pourraient être excellentes.
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.
1/ implémenter un protocole pour demander au serveur d'affichage de mapper la mémoire vidéo dans la mémoire de l'appli c'est parfaitement possible
2/ le DGA sous GNU/Linux, il faut avoir les droits roots. Avec un protocole bien conçu, il est possible de faire sur un multi-serveur sans avoir de droit root (juste un token "dga")
Oui, mais qu'est-ce qui m'empêche d'implanter la même optimisation sur noyau monolithique ?
Fais-le, et on verra. Le kernel space et l'user space sont deux espaces distincts. Faire une opération de 'grant' ou de 'map' entre deux programmes en espace utilisateur (le client et le driver) c'est la base de l'IPC de L4, c'est extrêment simple. Permettre au driver de taper directement dans la mémoire de l'application, sachant que le driver fonctionne de manière asynchrone et que l'appel write() peut être non-bloquant est quelque chose de beaucoup plus complexe. Presque infaisable.
Effectivement, on a un avantage au niveau de la securité (que je n'ai pas nié). et un peu avant Donc je ne vois pas de raison technique de passer sur un micro noyau.
Heu... contradiction là ?
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.
Là, j'aimerais bien savoir comment.
Mais je préfère la rapidité.
Mais tu n'as pas plus de rapidité !