Thanks for your advice and hope your continue attention on Luvalley. Regards, Xiaodong 2009/5/11 Dong, Eddie <eddie.dong@xxxxxxxxx>: > Xiaodong Yi wrote: >> 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. >> > > A typical issue in VMM benchmarking using OS benchmark such as what you used is time inaccurate issue. > > Benchmarks using guest time won't be able to get a right time or right duration due to scheduler etc, and thus VMM benchmarks is using network time for measuring such as vConsolidate. Spec.org is definning their benchmark for VMM, and I believe they will use network time too. > > For simplicity, you may continue use OS benchmark to measure VMM, but then you need to calibrate guest time accuracy first such as using stop watch etc. In both Xen & KVM, we benchmark using OS benchmark too, but it is usually only to see improvement of a performance patch. Formal benchmark data needs to consult wall clock or stop watch. > > Thx, eddie -- 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
