On Wednesday 05 March 2008 12:25:07 Anthony Liguori wrote: > 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&gro > >up_id=180599). You can simple using "sleep" to test it. And many people > > complained it before, e,g, > > http://www.mail-archive.com/kvm-devel@lists.sourceforge.net/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
Um... I see the problem. I haven't test IA32e RHEL4 before(tested Windows XP, RHEL5 PAE/IA32e, RHEL5.1 pae with default kernel parameter), and seems it got same problem with pae RHEL4 (I almost forgot that problem, thanks for reminder :) ). I have to tested it with "clock=pit", and it get exactly 3min for 3min in real time. But without it, the timer run much faster... You see, this patch can only guarantee PIT interrupts was injected correctly... I think the problem on RHEL4 expose another timer bug, like the pae smp RHEL5 before. I would do some investigate. > 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. For the irq chip is in kernel, and userspace pit can't touch it, I think in kernel PIT is proper one to solve the problem - clear, and light weight for this kind of very frequent calling. > > 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. -- Thanks Yang, Sheng ------------------------------------------------------------------------- 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
