From: "David S. Ahern" <daahern@cisco.com>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, KVM list <kvm@vger.kernel.org>
Subject: [Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace
Date: Mon, 07 Jun 2010 12:54:16 -0600 [thread overview]
Message-ID: <4C0D4058.3060009@cisco.com> (raw)
In-Reply-To: <4C0D3EA3.1010205@redhat.com>
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@vger.kernel.org/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
next prev parent reply other threads:[~2010-06-07 18:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-07 15:26 [Qemu-devel] [RFC] Moving the kvm ioapic, pic, and pit back to userspace Avi Kivity
2010-06-07 16:31 ` [Qemu-devel] " David S. Ahern
2010-06-07 18:46 ` Avi Kivity
2010-06-07 18:54 ` David S. Ahern [this message]
2010-06-07 19:16 ` Avi Kivity
2010-06-07 17:04 ` Anthony Liguori
2010-06-07 18:42 ` Avi Kivity
2010-06-07 22:23 ` Anthony Liguori
2010-06-08 5:48 ` Avi Kivity
2010-06-09 15:59 ` [Qemu-devel] " Dong, Eddie
2010-06-09 16:05 ` [Qemu-devel] " Avi Kivity
2010-06-10 2:37 ` [Qemu-devel] " Dong, Eddie
2010-06-10 2:59 ` [Qemu-devel] " Avi Kivity
2010-06-10 14:42 ` [Qemu-devel] " Dong, Eddie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C0D4058.3060009@cisco.com \
--to=daahern@cisco.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).