Yang, Sheng wrote: > On Wednesday 05 March 2008 08:50:24 Anthony Liguori wrote: > >> So how do we measure the benefits of an in-kernel PIT? >> > > On the time accuracy side, one typical example is in RHEL5 32E guest, time > flows very slow compared to the host > (https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1826080&group_id=180599). > > You can simple using "sleep" to test it. And many people complained it > before, e,g, > http://www.mail-archive.com/[email protected]/msg10928.html > And I have to say the timer problem in current KVM is very serious, and this > patch can solve this. >
Okay, then my question is, how much does this patch set improve the situation? For instance, the bug report shows some circumstances where: On IA32e RHEL4 guest with Realtime 3min Guest 3min15s So what is the guest time with an in-kernel PIT? How is this affected by the various possible -clock options? What I'm looking for is an example of how much we're improving the situation and some assurance that this is the only way to solve the problem. I'm not fundamentally opposed to an in-kernel PIT, I just am trying to understand the justification. Regards, Anthony Liguori > I think you are most worrying about the regressions. That's why I spent a lot > of time to solve TSC problem (PAE SMP RHEL5.1 can't boot up). For in kernel > PIT accelerate the process, the same bug was exposed on PAE SMP RHEL5 with > the patch. Though I don't think it's a real regression, I have got it done to > prevent this patch bring any bad effect. > > I would do more test to ensure this patch won't break something. > ------------------------------------------------------------------------- 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/ _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
