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

[Anthony Liguori <anthony@codemonkey.ws>]

Dor Laor wrote:
> On Tue, 2008-03-04 at 09:52 -0600, Anthony Liguori wrote:
>   
>> Yang, Sheng wrote:
>>     
>>> Hi
>>>
>>> Here is the last in-kernel PIT patch for KVM. The mainly change from last 
>>> version is the supporting to save/restore. I also tested live migration.
>>>
>>> The other modifies including some date structure changed to be better for 
>>> supporting the save/restore. I moved the PIT timer to outside of channel 
>>> structure, which explicitly means only one channel (channel 0) would trigger 
>>> it.
>>>
>>> After fix TSC problem on SMP PAE RHEL5/5.1 guest, now the patch works well 
>>> without any modify of kernel parameter.
>>>   
>>>       
>> How are you measuring the improvements from an in-kernel PIT?  From your 
>> mails, you're claiming it increases the timer accuracy.  How are you 
>> measuring it and how much does it improve it?
>>
>>     
>
> It's also a functionality addition: userspace pit & pic combination
> needed to use -tdf option (time drift fix). The tdf took care of pending
> pit irqs and tried to make the guest ack the right number of irqs the
> pit was configured.
>   

I thought there was some discussion about whether -tdf was every useful 
in practice?

> Once we switched to the default in-kernel pic, the userspace pit
> couldn't get the acks from the pit.
> One can see the effect when running multiple guests (windows, standard
> HAL) playing video, the time slows down.
>   

Okay, that makes sense.  So have you done any tests to confirm this?  We 
suffered through a fair number of regressions when we moved to an 
in-kernel APIC.  Before moving another big chunk of code in the kernel 
and going through possible regressions, I want to make sure we have a 
measurable argument that it's the right thing to do.

So how do we measure the benefits of an in-kernel PIT?

Regards,

Anthony Liguori

> This patch set has a pending counter and takes care for it too.
>
>   
>> Do you expect an overall performance improvement from this or is it 
>> simply about improving timer accuracy?
>>
>>     
>
> It will probably help older kernels with slow HZ run faster HZ guests.
> Without CONFIG_DYNTICK the guests behaved jumpy because of that.
>
>   
>> Regards,
>>
>> Anthony Liguori
>>
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>     
>
>   


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