From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: QEMU PIC indirection patch for in-kernel APIC work Date: Thu, 05 Apr 2007 09:40:34 +0300 Message-ID: <461499E2.7040905@qumranet.com> References: <4610A6A9.BA47.005A.0@novell.com> <46134B74.1080004@qumranet.com> <4613B438.60107@codemonkey.ws> <4613B89F.8090806@qumranet.com> <4613BC6B.1070708@codemonkey.ws> <4613BF07.50606@qumranet.com> <4613C993.9020405@codemonkey.ws> <4613CC01.1090500@qumranet.com> <4613CDB2.4000903@codemonkey.ws> <4613D001.3040606@qumranet.com> <20070404200112.GA6070@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Ingo Molnar Return-path: In-reply-to: <20070404200112.GA6070-X9Un+BFzKDI@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 Ingo Molnar wrote: > * Avi Kivity wrote: > > >>> It still exists in userspace. Having the code duplication >>> (especially when it's not the same code base) is unfortunate. >>> >> This remains true. >> > > but it's the wrong argument. Of course there's duplicate functionality, > and that's _good_ because it represents choice. KVM _itself_ is > duplicate functionality of qemu in a way. So why move the lapic/PIC > handling to the kernel? Because it's alot cleaner to do device emulation > there and PV drivers get significantly easier to do. The lapic/PIC code > should also be available in Qemu for OSs that dont have KVM-alike > support in the kernel. > Duplicating code is never good, and duplicating code into the kernel (where maintenance cost is much higher) is bad. There has to be a very good reason for it. For the core kvm code, it is the 10x or more performance increase over qemu. If we are to add *pic/pit to kvm, we need to find an advantage that offsets the disadvantages. This can be a combination of simpler interfaces and better performance. > and while today most of the performance advantages of moving the PIC > into the kernel are masked by the high cost of VM exits, in the future > the effect will be more marked, as the relative cost of piggybacking out > to qemu increases. > That is correct, but we need to quantify it. Assuming 3us per qemu exit overhead, 30,000 events per second per core give us a 10% overall overhead. That's >100K events/sec for an entry-level server. > I can see the value in doing certain things in Qemu, but i cannot see > _at all_ the value of handling say the PIT in Qemu. Just look at the > Qemu PIT/timers code quality in Qemu for a change ... it's a huge ugly > mess of lots of #ifdefs, ineffective handling of /dev/rtc, linear list > walking, signal overhead, etc., etc. Bad userspace code should be fixed, not rewritten as kernel code. > All of that resulting in 10-15% of > 'idle' overhead of KVM+qemu when it runs a Linux guest. On my machines it's 0% overhead on idle (runlevel 3). > On the other > side, in the kernel it's most natural to do timers and to emulate > hardware, because the kernel has _precise_ knowledge about the > platform's capabilities. > That comes back to the kernel not exporting proper interfaces. I think that's fixed now, with hrtimers tied to the userspace APIs? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- 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