Avi Kivity wrote: > Nakajima, Jun wrote: >> Most of H/W-virtualization capable processors out there don't support >> that feature today. I think the decision (kvm or qemu) should be done >> based on performance data. I'm not worried about maintenance issues; >> the APIC code is not expected to change frequently. I'm a bit >> worried about extra complexity caused by such split, though. >> >> > > In principle we could measure the performance cost today with the > pv-net driver; however it still does a lot of copies which could be > eliminated. > >> BTW, I see CPU utilization of qemu is almost always 99% in the top >> command when I run kernel build in an x86-64 Linux guest. >> > > Isn't that expected? if your guest image is mostly cached in the host, > the guest would have nothing to block on.
I compared the performance on Xen and KVM for kernel build using the same guest image. Looks like KVM was (kvm-17) three times slower as far as we tested, and that high load of qemu was one of the symptoms. We are looking at the shadow code, but the load of qemu looks very high. I remember we had similar problems in Xen before, but those were fixed. Someone should take a look at the qemu side. Jun --- Intel Open Source Technology Center ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
