qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy lo


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load.
Date: Sun, 09 Nov 2008 10:36:59 -0600
User-agent: Thunderbird 2.0.0.17 (X11/20080925)

Gleb Natapov wrote:
On Thu, Nov 06, 2008 at 09:37:56AM -0600, Anthony Liguori wrote:
Yes indeed. With raw image copy benchmark no longer runs enough time to
produce time drift big enough to be visible. So I ran this disk test
utility http://69.90.47.6/mybootdisks.com/mybootdisks_com/nu2/bst514.zip
for ~12 hours and the time drift was 12 secs (if I weren't so lazy and
wrote bat file to copy c:\windows in a loop I am sure result would be the
same). This is on completely idle host.

What frequency is the guest running at? If it's running at 100hz, then it missed a tick once every 36 seconds. This means that the guest couldn't run long enough to handle a timer interrupt (which should be a relatively small number of cycles) in a 10ms period.

Does this drift go away with the TDF patches? This almost makes me think that we aren't delivering interrupts at the right frequency and we're simply accumulating error. In theory, the TDF patches shouldn't help that.

Otherwise, I'm curious if you have any insight into where we're pausing for 10ms that's causing the missed interrupt?

We could also be missing ticks somehow. I think this warrants further investigation.

Regards,

Anthony Liguori

I think the best ones are going to be intense host workload (and let's see how much is needed before we start drifting badly) and high guest frequencies with hosts that lack high resolution timers. I think with a high resolution guest and no host overcommit, it should be very difficult to produce drift regardless of what the guest is doing.

Later I'll try to generate load on a host an see how this affects
guest's time drift.

--
                        Gleb.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]