Anthony Liguori wrote: > Dor Laor wrote: >> Anthony Liguori wrote: >>> The last time I posted the KVM patch series to qemu-devel, the -tdf >>> patch met with >>> some opposition. Since today we implement timer catch-up in the >>> in-kernel PIT and >>> the in-kernel PIT is used by default, it doesn't seem all that >>> valuable to have >>> timer catch-up in userspace too. >>> >>> Removing it will reduce our divergence from QEMU. >>> >>> >> IMHO the in kernel PIT should go away, there is no reason to keep it >> except that userspace PIT drifts. > > I agree fully :-) But there's certainly no reason to keep -tdf and the > in-kernel PIT. Since we're using the in-kernel PIT right now, I'd like > to get rid of -tdf. > >> Currently both in-kernel PIT and even the in kernel irqchips are not >> 100% bullet proof. >> Of course this code is a hack, Gleb Natapov has send better fix for >> PIT/RTC to qemu list. >> Can you look into them: >> http://www.mail-archive.com/[email protected]/msg01181.html > > Paul Brook's initial feedback is still valid. It causes quite a lot of > churn and may not jive well with a virtual time base. An advantage to > the current -tdf patch is that it's more contained. I don't think > either approach is going to get past Paul in it's current form. > > I'd still like to see some harder evidence of the benefits of tdf. For > a specific guest, with a specific configuration, how much better is the > drift with this series. The answer shouldn't be "movie's play better" :-) >
I for one see better timekeeping with RHEL3 guests -- especially when they get busy (e.g., kscand doing its thing). You see the "time drift" message every time it kicks in (the message does need to be throttled/not displayed by the way; it can overwhelm a stderr capture as the guest runs for months). > Also, it's important that this is reproducible in upstream QEMU and not > just in KVM. If we can make a compelling case for the importance of > this, we can possibly work out a compromise. I don't have an opinion on this particular implementation, only that something is needed to keep the guest from losing time. Right now with the kernel-pit my RHEL guests are always *ahead* of the host; with the qemu pit the guest is behind the host (which makes more sense if ticks are lost). Either way I'd like for the guest to not drift "noticeably" and when it does that ntpd is adequate to keep it in sync (I've noticed oddities with it too). david > > Regards, > > Anthony Liguori > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
