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

[Anthony Liguori <anthony@codemonkey.ws>]

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/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


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/