From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: QEMU PIC indirection patch for in-kernel APIC work Date: Wed, 04 Apr 2007 13:12:20 -0500 Message-ID: <4613EA84.3090404@us.ibm.com> References: <8FFF7E42E93CC646B632AB40643802A8025B96AA@scsmsx412.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: "Nakajima, Jun" Return-path: In-Reply-To: <8FFF7E42E93CC646B632AB40643802A8025B96AA-1a9uaKK1+wJcIJlls4ac1rfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Nakajima, Jun wrote: > 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. The KVM IDE emulation is much slower than Xen's. Part of that is the new AIO framework. It may be worth modifying the qemu_aio_init() function in block-raw.c to increase the AIO thread count, and trying with a SCSI disk. The SCSI disk with > 1 AIO thread is pretty good. Regards, Anthony Liguori > 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