[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Rethinking missed tick catchup
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] Rethinking missed tick catchup |
Date: |
Wed, 19 Sep 2012 19:57:32 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 |
On 09/19/2012 07:55 PM, Gleb Natapov wrote:
> On Wed, Sep 19, 2012 at 07:44:27PM +0300, Avi Kivity wrote:
>> On 09/19/2012 07:37 PM, Gleb Natapov wrote:
>> > On Wed, Sep 19, 2012 at 06:34:46PM +0300, Avi Kivity wrote:
>> >> On 09/16/2012 05:37 PM, Anthony Liguori wrote:
>> >> > Avi Kivity <address@hidden> writes:
>> >> >
>> >> >> On 09/13/2012 09:27 PM, Anthony Liguori wrote:
>> >> >>> If there was a better/equivalent solution that didn't depend on
>> >> >>> qemu-ga,
>> >> >>> I'd be all for it. But there isn't AFAICT.
>> >> >>
>> >> >> Perhaps there is. We fixed the problem for Linux by adding kvmclock
>> >> >> and
>> >> >> backporting it to distros that users are most likely to use. Windows
>> >> >> fixed the problem by adding their own pv clock interface. So we need
>> >> >> to
>> >> >> implement that, then focus on tick catchup for Windows XP and other
>> >> >> guests with no pv interface (*BSD, etc.)
>> >> >
>> >> > Tick catchup simply isn't going to work. That's the whole point of the
>> >> > thread.
>> >>
>> >> I'll restate. Windows and Linux don't need either qemu-ga or tick
>> >> catchup since they have pv time interfaces. FreeBSD and less frequently
>> >> used guests are unlikely to get a qemu-ga port, so they need tick
>> >> catchup. Is there reason to believe tick catchup won't work on FreeBSD?
>> >>
>> > If FreeBSD tries to compensate for lost ticks it may not work.
>>
>> Right, the problem is with guests that are too clever for their own
>> good. No idea where FreeBSD (or the others, just using it as a
>> placeholder) fall. But my guess is that the less popular the guest, the
>> fewer dirty tricks it pulls.
>>
>> >
>> >> >>
>> >> >> Those older guests are also less likely to have a qemu-ga port or
>> >> >> administrator motivation to install it.
>> >> >
>> >> > That's a strange assertion to make. FWIW, the issue with hibernation
>> >> > was reported to me with a combination of WinXP and Windows 7 guests, in
>> >> > this case, it's a totally new deployment. Adding qemu-ga is totally
>> >> > reasonable.
>> >>
>> >> Windows 7 doesn't need anything if we implement the pv time interface.
>> > What PV interface exactly? According to [1] Hyper-v also tries to
>> > "catch-up" timer by shortening timer period unless to many events were
>> > missed.
>> >
>> > [1]
>> > http://msdn.microsoft.com/en-us/library/windows/hardware/ff542561%28v=vs.85%29.aspx
>> >
>>
>> Reference Time Counter. If Windows uses that in preference to the tick,
>> then tick catch up is immaterial.
>>
> Windows uses it for QPC if iTSC (kvmclock) is not available. I am not at
> all sure Windows uses Reference Time Counter for time keeping.
Would be good to know, except...
>
>>
>> >> That is less effort than requiring a qemu-ga installation. Windows XP
>> >> is an edge case. We can of course support qemu-ga for it, or we can
>> >> massage the tick code to work with it, since it's timekeeping is likely
>> >> a lot less sophisticated than 7's.
>> >>
>> > How do you propose to "massage the tick code" to compensate for 100
>> > hours of missed ticks in a sane way?
>>
>> Probably not solvable. But I'm less concerned about host suspend and
>> more about overcommit, which is more likely to cause missed ticks in
>> practice.
>>
>> > As far as I know there is no
>> > difference in timekeeping between Windows XP and Windows 7 (at least
>> > without PV).
>>
>> Including the rtc resync?
>>
> You mean resync time with RTC from time to time. I think so. In practice
> I didn't hear any complains about it for any Windows. We can solve
> resync problem easily though by reporting time as "current time" - "time we
> going to reinject"
Clever! I think this is a point in favour of tick catchup (also, the
fact the hyper-v uses it). Of course it's hard to implement with some
time sources in the kernel and some in qemu.
--
error compiling committee.c: too many arguments to function
- Re: [Qemu-devel] Rethinking missed tick catchup, (continued)
- Re: [Qemu-devel] Rethinking missed tick catchup, Avi Kivity, 2012/09/13
- Re: [Qemu-devel] Rethinking missed tick catchup, Anthony Liguori, 2012/09/13
- Re: [Qemu-devel] Rethinking missed tick catchup, Avi Kivity, 2012/09/13
- Re: [Qemu-devel] Rethinking missed tick catchup, Anthony Liguori, 2012/09/13
- Re: [Qemu-devel] Rethinking missed tick catchup, Avi Kivity, 2012/09/16
- Re: [Qemu-devel] Rethinking missed tick catchup, Anthony Liguori, 2012/09/16
- Re: [Qemu-devel] Rethinking missed tick catchup, Avi Kivity, 2012/09/19
- Re: [Qemu-devel] Rethinking missed tick catchup, Gleb Natapov, 2012/09/19
- Re: [Qemu-devel] Rethinking missed tick catchup, Avi Kivity, 2012/09/19
- Re: [Qemu-devel] Rethinking missed tick catchup, Gleb Natapov, 2012/09/19
- Re: [Qemu-devel] Rethinking missed tick catchup,
Avi Kivity <=
- Re: [Qemu-devel] Rethinking missed tick catchup, Anthony Liguori, 2012/09/13
- Re: [Qemu-devel] Rethinking missed tick catchup, Gleb Natapov, 2012/09/13
- Re: [Qemu-devel] Rethinking missed tick catchup, Avi Kivity, 2012/09/13
- Re: [Qemu-devel] Rethinking missed tick catchup, Anthony Liguori, 2012/09/13
- Re: [Qemu-devel] Rethinking missed tick catchup, Gleb Natapov, 2012/09/13
- Re: [Qemu-devel] Rethinking missed tick catchup, Anthony Liguori, 2012/09/13
- Re: [Qemu-devel] Rethinking missed tick catchup, Gleb Natapov, 2012/09/13
- Re: [Qemu-devel] Rethinking missed tick catchup, Anthony Liguori, 2012/09/13
- Re: [Qemu-devel] Rethinking missed tick catchup, Avi Kivity, 2012/09/13
- Re: [Qemu-devel] Rethinking missed tick catchup, Gleb Natapov, 2012/09/13