It is not a typo. I copied from UnixBench output directly. Howver, it must be a bug of Luvalley because even the native Linux benchmark on Double-Precision Whetstone is not that high. I also noticed that other benchmarks are all lower than native Linux. About timing, Luvalley does nothing more than KVM except that Luvalley implemented the VLAPIC timer using TSC while KVM uses the services of Linux kernel. The other timers of both Luvalley and KVM, I think, are all implemented in Qemu. Moreover, I could not explain why Luvalley's benchmarks on process creation, execl throughput, file copy and shell script are 20% ~ 40% higher than KVM, while other benchmarks on pipe throughput, context switching and syscall overhead are almost the same as KVM. Thanks for your attention, Xiaodong 2009/4/19 Avi Kivity <avi@xxxxxxxxxx>: > Jan Kiszka wrote: >> Avi Kivity wrote: >> >>> Xiaodong Yi wrote: >>> >>>> Hi, >>>> >>>> I've tested the guest Linux using UnixBench 5.1.2. The platform is: >>>> * Intel's Core Due CPU with 2 cores, 2GB RAM >>>> * CentOS 5.2 as the dom0 Linux, i.e., the host Linux for KVM >>>> * CentOS 5.2 as the guest Linux, i.e., the Linux running on the >>>> virtual machine provided by Qemu >>>> >>>> The first set of results is for Luvalley, and the second one is for >>>> KVM. As the result, Luvalley's guest Linux is 20% ~ 30% faster than >>>> KVM's guest! It is very surprise to me. I had through Luvalley's guest >>>> should be the same performance as KVM's. >>>> >>>> >>>> >>> Yes, it is surprising. >>> >>> >>>> Double-Precision Whetstone 12287.7 MWIPS (10.0 s, 2 samples) >>>> Double-Precision Whetstone 2166.3 MWIPS (10.2 s, 2 samples >>>> >>> That's by far the biggest difference. Can you confirm it isn't a typo? >>> >>> If not, then it looks like we have a bug in floating point handling. I >>> don't think this benchmark uses sse. >>> >>> >> >> Even the native Linux numbers are not that high, rather comparable to >> KVM. I suspect Luvalley is fooling the benchmark here... >> > > Most likely timing. Likely Luvally guests time runs to slowly, so they > achieve more loops per unit of guest time. > > -- > Do not meddle in the internals of kernels, for they are subtle and quick to panic. > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
