Ingo Molnar wrote: > * Avi Kivity <[EMAIL PROTECTED]> 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 _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
