qemu vs qemu-kvm: algunas mediciones de rendimiento

Question

I realizó el siguiente punto de referencia en qemu y qemu-kvm, con la siguiente configuración:

CPU: AMD 4400 process dual core with svm enabled, 2G RAM 
Host OS: OpenSUSE 11.3 with latest Patch, running with kde4 
Guest OS: FreeDos 
Emulated Memory: 256M 
Network: Nil 
Language: Turbo C 2.0 
Benchmark Program: Count from 0000000 to 9999999. Display the counter on the screen 
    by direct accessing the screen memory (i.e. 0xb800:xxxx) 

sólo toma 6 seg cuando se ejecuta en qemu.

Pero lleva 89 segundos cuando se ejecuta en qemu-kvm.

Corrí el punto de referencia uno por uno, no en paralelo.

Me rasqué la cabeza toda la noche, pero todavía no tengo idea de por qué sucede esto. ¿Alguien me daría algunas pistas?

Answer 1

Su punto de referencia es un punto de referencia intensivo IO y todos los dispositivos io son realmente los mismos para qemu y qemu-kvm. En el código fuente de qemu esto se puede encontrar en hw/*.

Esto explica que el qemu-kvm no debe ser muy rápido en comparación con qemu. Sin embargo, no tengo una respuesta particular para la desaceleración. Tengo la siguiente explicación para esto y creo que es correcta en gran medida.

"El módulo qemu-kvm utiliza el módulo kernel kvm en el kernel de Linux. Esto ejecuta el invitado en modo invitado x86 que causa una trampa en cada instrucción privilegiada. Por el contrario, qemu usa un TCG muy eficiente que traduce las instrucciones ve en el primer momento. I piensa que el alto costo de la trampa se muestra en sus puntos de referencia ". Esto no es cierto para todos los io-dispositivos sin embargo. El punto de referencia de Apache funcionaría mejor en qemu-kvm porque la biblioteca realiza el almacenamiento en búfer y usa la menor cantidad de instrucciones privilegiadas para hacer el IO.

Answer 2

KVM usa qemu como su simulador de dispositivo, cualquier operación del dispositivo es simulada por el programa de espacio de usuario QEMU. Cuando escribe en 0xB8000, la pantalla gráfica funciona, lo que implica que el invitado haga una CPU `vmexit 'desde el modo invitado y regrese al módulo KVM, que a su vez envía solicitudes de simulación de dispositivo al espacio de usuario QEMU back-end.

Por el contrario, QEMU sin KVM realiza todos los trabajos en un proceso unificado, excepto las llamadas al sistema habituales, hay menos conmutadores de contexto de CPU. Mientras tanto, su código de referencia es un bucle simple que solo requiere code block translation por una sola vez. Eso no cuesta nada, en comparación con vmexit y la comunicación kernel-usuario de cada iteración en el caso de KVM.

Esta debería ser la causa más probable.

Answer 3

El motivo es que se realiza demasiado VMEXIT.