On 06/07/10 12:46, Avi Kivity wrote: > 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. > Aps that invoke gettimeofday a lot. As I recall RHEL3 uses the TSC between timer interrupts, but RHEL4 samples counters on each gettimeofday call: http://www.mail-archive.com/kvm@xxxxxxxxxxxxxxx/msg07231.html Because of that performance of applications that timestamp log entries (like a certain product I work on) takes a hit on KVM unless the TSC is the clock source. David -- 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
