Anthony Liguori wrote: > Avi Kivity wrote: >> Anthony Liguori wrote: >> >>> Implemented a hypercall queue that can be used when paravirt_ops >>> lazy mode >>> is enabled. This patch enables queueing of MMU write operations and CR >>> updates. This results in about a 50% bump in kernbench performance. >>> >> >> Nice! But 50%? a kernel build is at native-25%, so we're now 25% >> faster than native? > > Well, I haven't measured KVM to be 25% of native with kernbench :-) > On my LS21 (AMD), I get:
I did, but using kbuild (a simple 'make' with defconfig), not kernbench. I get (elapsed time) 308 sec for kvm and 243 sec for native. Intel however is much faster than AMD due to the recent optimizations, and I guess we get some pagetable thrashing with kernbench vs. kbuild. > > KVM > Elapsed Time 1054.39 (25.8237) > User Time 371.844 (8.57204) > System Time 682.61 (17.7778) > Percent CPU 99.8 (0.447214) Sleeps 50115 (475.693) > > KVM PV > Elapsed Time 595.85 (13.7058) > User Time 360.99 (9.56093) > System Time 234.704 (4.21283) > Percent CPU 99 (0) > Context Switches 46989.8 (328.277) > Sleep 47882.8 (242.583) > > NATIVE > Elapsed Time 328.602 (0.212415) > User Time 304.364 (0.353171) > System Time 23.99 (0.325192) > Percent CPU 99 (0) > Context Switches 39785.2 (159.796) > Sleeps 46398.6 (311.466) > > With Intel, we're still only about 60% of native to start out with. > The PV patches take us to about 72%. > These numbers are pretty bad. I'd like to improve them, even without PV. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
