En fait, il est loin d'être évident que UML soit plus performant que du Qemu (avec du kqemu en mode kernel) ou du vmware, particulièrement dans le cas de code avec beaucoup de syscalls (typiquement, quand il y a des I/O à la pelle).
Le problème est que pour pouvoir faire tourner du code non modifié, UML doit pouvoir émuler les syscalls en userland. Or pour cela, il n'y a pas énormement de solutions. En l'occurrence, UML surveille l'exécution via ptrace(). Donc à chaque syscall d'un processus guest, il va avoir un switch userland -> kernelland, le kernel s'aperçoit que y'a du ptrace(), retour en userland coté UML, UML fait disparaitre d'un coup de baguette magique le syscall original (et doit laisser probablement un syscall bidon s'exécuter, donc 2 switchs à nouveau), puis s'occupe d'émuler le syscall, ce qui signifie probablement souvent plusieurs syscalls et donc switch userland/kernelland. Et ensuite, 2 derniers switchs pour continuer l'exécution du processus guest.
Or le problème c'est que du switch kernelland/userland, c'est extrêmement lent (un long call c'est rien à coté), d'où des perfs qui s'écroulent des qu'il y a des I/O.
Xen, pour éviter cela, joue avec les ring 1/2 des x86 (chose qui existe sur peu d'autres processeurs, beaucoup n'ayant que 2 modes, kernel & user, contre 4 pour les x86).
Je ne prétends pas que qemu/kernelkqemu & vmware sont systématiquement plus rapides que UML, mais juste que les perfs d'UML ne sont certainement pas à rapprocher de Xen. J'aimerais bien mettre en place qq benchmarks, mais le temps n'étant pas extensible, c'est pas gagné ...
(et je soupçonne que CoLinux ai le même problème - mais là c'est de la pure spéculation :)
# Performances de UML
Posté par Pierre Palatin . En réponse à la dépêche Virtualisation de Serveur : Linux sous Windows. Évalué à 7.
Clairement, ça reste moins performant que du Xen, cf les benchmarks (venant de l'équipe de xen certes) : http://www.cl.cam.ac.uk/Research/SRG/netos/xen/performance.h(...)
Le problème est que pour pouvoir faire tourner du code non modifié, UML doit pouvoir émuler les syscalls en userland. Or pour cela, il n'y a pas énormement de solutions. En l'occurrence, UML surveille l'exécution via ptrace(). Donc à chaque syscall d'un processus guest, il va avoir un switch userland -> kernelland, le kernel s'aperçoit que y'a du ptrace(), retour en userland coté UML, UML fait disparaitre d'un coup de baguette magique le syscall original (et doit laisser probablement un syscall bidon s'exécuter, donc 2 switchs à nouveau), puis s'occupe d'émuler le syscall, ce qui signifie probablement souvent plusieurs syscalls et donc switch userland/kernelland. Et ensuite, 2 derniers switchs pour continuer l'exécution du processus guest.
Or le problème c'est que du switch kernelland/userland, c'est extrêmement lent (un long call c'est rien à coté), d'où des perfs qui s'écroulent des qu'il y a des I/O.
Xen, pour éviter cela, joue avec les ring 1/2 des x86 (chose qui existe sur peu d'autres processeurs, beaucoup n'ayant que 2 modes, kernel & user, contre 4 pour les x86).
Je ne prétends pas que qemu/kernelkqemu & vmware sont systématiquement plus rapides que UML, mais juste que les perfs d'UML ne sont certainement pas à rapprocher de Xen. J'aimerais bien mettre en place qq benchmarks, mais le temps n'étant pas extensible, c'est pas gagné ...
(et je soupçonne que CoLinux ai le même problème - mais là c'est de la pure spéculation :)