Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace

[Avi Kivity <avi@redhat.com>]

On 06/07/2010 07:31 PM, David S. Ahern wrote:
>
> On 06/07/10 09:26, Avi Kivity wrote:
>
>    
>> The original motivation for moving the PIC and IOAPIC into the kernel
>> was performance, especially for assigned devices.  Both devices are high
>> interaction since they deal with interrupts; practically after every
>> interrupt there is either a PIC ioport write, or an APIC bus message,
>> both signalling an EOI operation.  Moving the PIT into the kernel
>> allowed us to catch up with missed timer interrupt injections, and
>> speeded up guests which read the PIT counters (e.g. tickless guests).
>>
>> However, modern guests running on modern qemu use MSI extensively; both
>> virtio and assigned devices now have MSI support; and the planned VFIO
>> only supports kernel delivery via MSI anyway; line based interrupts will
>> need to be mediated by userspace.
>>      
> The "modern" guest comment is a bit concerning. 2.4 kernels (e.g.,
> RHEL3) use the PIT for timekeeping and will still be around for a while.
> RHEL4 and RHEL5 will be around for a long time to come. Not sure how
> those fit within the "modern" label, though I see my RHEL4 guest is
> using the pit as a timesource.
>    

First of all, the existing code will remain for a long while (several 
years).  We still have to support existing userspace.

But, that's not a satisfactory answer.  I don't want users to choose 
which device model to use according to their guest.  As far as I'm 
concerned all guests are triple-boot with the guest rebooting to a 
different OS every half hour.

So it's important to know how often your RHEL3/4 guest queries the PIT 
(not just receives interrupts, actually reads the counter) under a 
realistic load.  If you have such a number (in reads/sec) that would be 
a good input to this discussion.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.