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: Thu, 06 Nov 2008 08:10:45 -0600
User-agent: Thunderbird 2.0.0.17 (X11/20080925)

Gleb Natapov wrote:
On Wed, Nov 05, 2008 at 10:43:46AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:

Sorry, I mistyped. I meant to say, I don't think any of the problems raised when this was initially posted have been addressed. Namely, I asked for hard data on how much this helped things
Does my answer to Dor's mail provide enough data?

I'll try to reproduce locally. Your case would be more compelling with a more thorough analysis but I can at least now attempt to determine how hr timers impacts this.

How does having a high resolution timer in the host affect the problem to begin with?
My test machine has relatively recent kernel that use high resolution
timers for time keeping. Also the problem is that guest does not receive
enough time to process injected interrupt. How hr timer can help here?
If the host can awaken QEMU 1024 times a second and QEMU can deliver a timer interrupt each time, there is no need for time drift fixing.

It is not enough to wake QEMU process 1024 time a second to signal time
interrupt. A guest should also have enough time to run between each
interrupt to process it. If QEMU signals 1024 time interrupt a second
and guest process only half of that a second you'll see time drift.
And if guest asks for 1024hz frequency and guest can't provide that no
solution for time drift exists in that case.

If nothing else is running on the system, the guest should get plenty of time to run timers.

If the guest is not getting enough time on the system to be able to run their timer ticks, then coalescing the timer ticks isn't going to help by definition (they aren't getting enough CPU time to run these routines).

I would think that with high res timers on the host, you would have to put the host under heavy load before drift began occurring.

I see a time drift even with guest using 100hz timers and I am pretty sure
my 2.6.25 host uses hr timers.

You see time drift with 100hz timers in the guest?? That makes very little sense as even without hr timers, the host should have no problem delivering a 10ms timer. Note, we just fixed an issue with delayed timer deliver. There may be more bugs like this that are causing ticks to get missed. If you have nothing else running on the host, no matter what you do in the guest, I see absolutely no reason why time should drift if the guest is running a 100hz timer.

Do you have an explanation for this?

The windows guest is supposed to be able to tell the hypervisor which technique it should be using.

Do you have pointer to a documentation that describe it? I am especially
interested if old guest like windows XP and windows 2003 support this?
Surprisingly many people are interested in those old guests, not shiny
newer ones :)

http://www.microsoft.com/downloads/details.aspx?FamilyID=91e2e518-c62c-4ff2-8e50-3a37ea4100f5&DisplayLang=en

Regards,

Anthony Liguori

--
                        Gleb.





reply via email to

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