Je précise que je suis un profane en designe de micro kernel et de programmation système donc il faut prendre tout ce que je dis avec de très grosses pincettes.
Premièrement, selon http://en.wikipedia.org/wiki/Call_gate , Very few modern operating systems use call gates. With the introduction of SYSENTER/SYSEXIT and SYSCALL/SYSRET, a new faster mechanism was introduced for control transfers for x86 programs. Apparemment on pourrait y passer outre...
Ensuite, selon [1] (qui a 10 ans déja) The macrobenchmarks answer our first question. The current implementation of L4Linux comes reasonably close to the behavior of native Linux, even under high load. Typical penalties range from 5% to 10%. Actuellement, sur [5] (L4Linux2.6): However, the initial L4Linux has been somewhat optimized, and on L4/x86 it has a very acceptable slowdown of less than 4 % for any relevant load. Aussi selon [2], les context switch de wombat sont bien plus rapides que linux/ARM (d'autant que les messages sont petits). Évidemment ce n'est qu'un linux au dessus de l4 donc les programmes linux ont un double overhead, puisqu'ils passent d'abord par linux puis, les driver linux par l4 pour accéder aux ressources. Peut-on penser qu'un système complèt sur l4 serait plus rapide ?
Sinon, [3] & [4] contiennent des pistes vers des papiers intéressants. Enfin bon, ce que j'en retiens c'est que L4 a été designé pour avoir des ipc très rapides (optimisation des caches, petits messages incrustés dans les registres, exploitation sioux de la tlb, mmapping efficace,...) qui sont bien plus léger que faire un system call sous linux.
Enfin, l'avantage premier d'un micro-noyau ce n'est pas tellements ses performaces mais bien la sécurité qu'il apporte. Cela permet de relativiser beaucoup les différents benchmark. Note qu'apparemment il y aurait 2 grandes tendances pour imposer la sécurité: l'ipc indirection (l4) et les capabilities (eros, coyotos). Bon après je n'en sais pas plus.
[^] # Re: Précisions
Posté par benja . En réponse au journal Tanenbaum et les microkernels. Évalué à 3.
Premièrement, selon http://en.wikipedia.org/wiki/Call_gate , Very few modern operating systems use call gates. With the introduction of SYSENTER/SYSEXIT and SYSCALL/SYSRET, a new faster mechanism was introduced for control transfers for x86 programs. Apparemment on pourrait y passer outre...
Ensuite, selon [1] (qui a 10 ans déja) The macrobenchmarks answer our first question. The current implementation of L4Linux comes reasonably close to the behavior of native Linux, even under high load. Typical penalties range from 5% to 10%. Actuellement, sur [5] (L4Linux2.6): However, the initial L4Linux has been somewhat optimized, and on L4/x86 it has a very acceptable slowdown of less than 4 % for any relevant load. Aussi selon [2], les context switch de wombat sont bien plus rapides que linux/ARM (d'autant que les messages sont petits). Évidemment ce n'est qu'un linux au dessus de l4 donc les programmes linux ont un double overhead, puisqu'ils passent d'abord par linux puis, les driver linux par l4 pour accéder aux ressources. Peut-on penser qu'un système complèt sur l4 serait plus rapide ?
Sinon, [3] & [4] contiennent des pistes vers des papiers intéressants. Enfin bon, ce que j'en retiens c'est que L4 a été designé pour avoir des ipc très rapides (optimisation des caches, petits messages incrustés dans les registres, exploitation sioux de la tlb, mmapping efficace,...) qui sont bien plus léger que faire un system call sous linux.
Enfin, l'avantage premier d'un micro-noyau ce n'est pas tellements ses performaces mais bien la sécurité qu'il apporte. Cela permet de relativiser beaucoup les différents benchmark. Note qu'apparemment il y aurait 2 grandes tendances pour imposer la sécurité: l'ipc indirection (l4) et les capabilities (eros, coyotos). Bon après je n'en sais pas plus.
[1]: http://os.inf.tu-dresden.de/pubs/sosp97/
[2]: http://www.ertos.nicta.com.au/research/l4/performance.pml
[3]: http://en.wikipedia.org/wiki/L4_microkernel_family
[4]: http://l4ka.org/publications/
[5]: http://os.inf.tu-dresden.de/L4/LinuxOnL4/status.shtml