Re: [PATCH 0/6] In kernel PIT patch

["Yang, Sheng" <sheng.yang@intel.com>]

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/