On Wednesday 05 March 2008 08:50:24 Anthony Liguori wrote: > 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?
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. 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. > > 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 > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/kvm-devel -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
