From: Anthony Liguori <anthony@codemonkey.ws>
To: dor.laor@qumranet.com
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>,
Avi Kivity <avik@qumranet.com>
Subject: Re: windows acpi time drift
Date: Tue, 18 Mar 2008 18:57:38 -0500 [thread overview]
Message-ID: <47E056F2.6090804@codemonkey.ws> (raw)
In-Reply-To: <1205883223.21936.42.camel@localhost.localdomain>
Dor Laor wrote:
> On Wed, 2008-03-19 at 01:09 +0200, Dor Laor wrote:
>
>> After some research of time drift while using window windows acpi hal I
>> discovered it uses the ... rtc timer as a source clock.
>> Not the apic, acpi nor the pit. The acpi timer is not used by the time
>> keeping clock, the apic & pit timer irqs are masked.
>>
>> In order to fix the time drift we need to fix the rtc emulation.
>> The problem is that like the pit and the apic timers in userspace, the
>> rtc also has inaccurate timer, thus leading to irq coalescing before
>> getting acknowledged by the guest interrupt controller.
>>
>> We have two options:
>> 1. Bring another device to the kernel
>> - It's a simple device
>> - It will make the rtc clock more accurate (hrtimer)
>> - Easy time drift fix like apic/pic
>> - It has very minor performance improvment of canceling the
>> need to go to userspace after vmexit, thus not syncing vmcs.
>> But it's only 15msec * 2 rate.
>>
>
> Hmm, when doing multimedia, windows increases the frequency of rtc from
> 64HZ to 1024HZ, thus in-kernel device will save 2048 user-space exits.
> This might be a real improvement - small but measurable.
>
Well, let's calculate it. I measure a lightweight exit at 3590 cycles
and a heavyweight exit at 8548. If we look at the cost of dropping to
userspace an extra 2048 times, since I have a 2.2 GHz chip, we're
looking at an additional .0046 seconds to transition to userspace. This
is on top of the base .0033 seconds that it takes to take these exits in
the first place. This are dummy exits though so when you add in the
cost of processing this (which I think is roughly equal whether in
kernelspace or userspace) I think those values will quickly be overwhelmed.
So, at the end of the day, you're not getting even a 1% performance
boost and you're adding a lot of complexity to the kernel. This
strongly suggests to me that we should be doing this in userspace.
Regards,
Anthony Liguori
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
next prev parent reply other threads:[~2008-03-18 23:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-18 23:09 windows acpi time drift Dor Laor
2008-03-18 23:33 ` Dor Laor
2008-03-18 23:57 ` Anthony Liguori [this message]
2008-03-18 23:35 ` Anthony Liguori
2008-03-19 8:19 ` Avi Kivity
2008-03-19 14:09 ` Anthony Liguori
2008-03-19 15:39 ` Avi Kivity
2008-03-19 16:27 ` Dor Laor
2008-03-19 17:45 ` Avi Kivity
2008-03-19 0:07 ` Anthony Liguori
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=47E056F2.6090804@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=avik@qumranet.com \
--cc=dor.laor@qumranet.com \
--cc=kvm-devel@lists.sourceforge.net \
/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