Re: QEMU PIC indirection patch for in-kernel APIC work

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Ingo Molnar wrote:
> * Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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