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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
