Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
On Thu, 2008-03-06 at 14:56 -0600, Anthony Liguori wrote: > Avi Kivity wrote: > > > >> The thing I'm trying to get at is a quantitative statement about why > >> moving the pit into the kernel is the right thing. I'll try to give > >> the patches a try myself in the next couple of days. I don't think > >> it's obvious that it's the right thing to do without some sort of > >> benchmark supporting it. > >> > > > > Playing a movie is better than any benchmark; it reflects actual user > > experience in a real and important use case. Benchmarks are > > substitutes for real use cases, not the goal of the optimization. > > I tried out WinXP with the standard HAL and the in-kernel APIC patches. > I did not see any appreciable improvement in multimedia playback (video > or audio). I still get the same amount of jitters. I've tried with and > without -tdf too. > > So far, the smoothest play back I've gotten is using the ACPI HAL. Can > you point to a particular example where you see an improvement? Perhaps > a divx or movie trailer that is better with it than without it? > ACPI HAL should perform good. The in kernel PIT should fix time drift on standard HAL when playing movies (pit freq -> 1000hz) and the host cpu is loaded. If the host is not loaded you might not see the drift. Use kernel build or tgz + taskset to load the cpu. Without the patches in-kernel PIC should time drift and userspace PIC + -tdf shouldn't. As for quality, sometimes when time drifts the movies looks smoother but that's not really the required result. > 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
Avi Kivity wrote: > >> The thing I'm trying to get at is a quantitative statement about why >> moving the pit into the kernel is the right thing. I'll try to give >> the patches a try myself in the next couple of days. I don't think >> it's obvious that it's the right thing to do without some sort of >> benchmark supporting it. >> > > Playing a movie is better than any benchmark; it reflects actual user > experience in a real and important use case. Benchmarks are > substitutes for real use cases, not the goal of the optimization. I tried out WinXP with the standard HAL and the in-kernel APIC patches. I did not see any appreciable improvement in multimedia playback (video or audio). I still get the same amount of jitters. I've tried with and without -tdf too. So far, the smoothest play back I've gotten is using the ACPI HAL. Can you point to a particular example where you see an improvement? Perhaps a divx or movie trailer that is better with it than without it? 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
On Wed, 2008-03-05 at 17:05 -0600, Anthony Liguori wrote: > Dor Laor wrote: > > On Wed, 2008-03-05 at 19:30 +0200, Avi Kivity wrote: > > > >> > >> Playing a movie is better than any benchmark; it reflects actual user > >> experience in a real and important use case. Benchmarks are substitutes > >> for real use cases, not the goal of the optimization. > >> > >> > > > > I forgot to mention that the benchmark is measuring time drift in the > > guest. Playing a movie in winxp changes the guest clock frequency from > > 100HZ to 1000HZ, thus causing a 250HZ host to coalesce pit irqs. > > > > So good pic & pit combination can handle guest multimedia without drifts > > while insufficient implementation just can't. > > > > I'll try out these patches in the next day or so. Is the expectation > that Standard HAL + in-kernel APIC/PIT will have smoother playback than > ACPI HAL w/o in-kernel APIC/PIT? I presume that the ACPI HAL is > unaffected by in-kernel PIT? > Standard HAL + userspace pic + -tdf option should give no guest time drift (actually sometimes massive correction of irq injection do the opposite, also since time drifts without -dtf it might look better but the movie does not runs in real time). Standard HAL + in-kernel pit patch + in-kernel irqchip should not drift. All other combinations should drift (sometimes you need to overload the cpu to see the drift). As for ACPI hal, the in-kernel apic doesn't drift, it also enable having flex priority or Avi's tpr optimization that boost overall performance. ACPI HAL should not be affected by the in-kernel pit. > 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
Dor Laor wrote: > On Wed, 2008-03-05 at 19:30 +0200, Avi Kivity wrote: > >> >> Playing a movie is better than any benchmark; it reflects actual user >> experience in a real and important use case. Benchmarks are substitutes >> for real use cases, not the goal of the optimization. >> >> > > I forgot to mention that the benchmark is measuring time drift in the > guest. Playing a movie in winxp changes the guest clock frequency from > 100HZ to 1000HZ, thus causing a 250HZ host to coalesce pit irqs. > > So good pic & pit combination can handle guest multimedia without drifts > while insufficient implementation just can't. > I'll try out these patches in the next day or so. Is the expectation that Standard HAL + in-kernel APIC/PIT will have smoother playback than ACPI HAL w/o in-kernel APIC/PIT? I presume that the ACPI HAL is unaffected by in-kernel PIT? 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
On Wed, 2008-03-05 at 19:30 +0200, Avi Kivity wrote: > Anthony Liguori wrote: > > Playing a movie is a bit subjective. I presume you're talking about the > > standard HAL as presumably the ACPI HAL is using the pm timer? > > > > ACPI HAL uses the apic timer, IIRC; perhaps the pm timer as well. > > > So the two cases I'm hearing where timer accuracy should improve is > > standard HAL on Windows and clock=pit on Linux? I'd still like to see > > what the actual difference in timer accuracy is. > > It depends on the load. As the load increases, the host process starts > to miss timer signals. With both pic and pit in userspace, you can > detect those missed interrupts and inject them later once you get your > timeslice. With the pic in kernel, there is no way to do this. > > The same thing happens with the apic timer, only there, it is easy to > compensate because both parts are in the kernel. > > > I have no doubt that > > moving the pit into the kernel is more efficient. Moving everything > > into the kernel is more efficient because light weight exits are cheaper > > than heavy weight exits. > > > > Efficiency is only a secondary goal here. The userspace PIT does not > consume large amounts of CPU. > > > The thing I'm trying to get at is a quantitative statement about why > > moving the pit into the kernel is the right thing. I'll try to give the > > patches a try myself in the next couple of days. I don't think it's > > obvious that it's the right thing to do without some sort of benchmark > > supporting it. > > > > Playing a movie is better than any benchmark; it reflects actual user > experience in a real and important use case. Benchmarks are substitutes > for real use cases, not the goal of the optimization. > I forgot to mention that the benchmark is measuring time drift in the guest. Playing a movie in winxp changes the guest clock frequency from 100HZ to 1000HZ, thus causing a 250HZ host to coalesce pit irqs. So good pic & pit combination can handle guest multimedia without drifts while insufficient implementation just can't. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
Anthony Liguori wrote: > Playing a movie is a bit subjective. I presume you're talking about the > standard HAL as presumably the ACPI HAL is using the pm timer? > ACPI HAL uses the apic timer, IIRC; perhaps the pm timer as well. > So the two cases I'm hearing where timer accuracy should improve is > standard HAL on Windows and clock=pit on Linux? I'd still like to see > what the actual difference in timer accuracy is. It depends on the load. As the load increases, the host process starts to miss timer signals. With both pic and pit in userspace, you can detect those missed interrupts and inject them later once you get your timeslice. With the pic in kernel, there is no way to do this. The same thing happens with the apic timer, only there, it is easy to compensate because both parts are in the kernel. > I have no doubt that > moving the pit into the kernel is more efficient. Moving everything > into the kernel is more efficient because light weight exits are cheaper > than heavy weight exits. > Efficiency is only a secondary goal here. The userspace PIT does not consume large amounts of CPU. > The thing I'm trying to get at is a quantitative statement about why > moving the pit into the kernel is the right thing. I'll try to give the > patches a try myself in the next couple of days. I don't think it's > obvious that it's the right thing to do without some sort of benchmark > supporting it. > Playing a movie is better than any benchmark; it reflects actual user experience in a real and important use case. Benchmarks are substitutes for real use cases, not the goal of the optimization. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
Dor Laor wrote: > On Tue, 2008-03-04 at 18:50 -0600, Anthony Liguori wrote: > >> Dor Laor wrote: >> >> I thought there was some discussion about whether -tdf was every useful >> in practice? >> > > It works. > Just try to play a movie in windows standard HAL with and w/o -tdf > --no-irq-chip and you'll see the difference. > I don't have a VM with the standard HAL but I'll take your word for it. >> >> So how do we measure the benefits of an in-kernel PIT? >> > > Play the same movie using the kernel's pit. > Playing a movie is a bit subjective. I presume you're talking about the standard HAL as presumably the ACPI HAL is using the pm timer? So the two cases I'm hearing where timer accuracy should improve is standard HAL on Windows and clock=pit on Linux? I'd still like to see what the actual difference in timer accuracy is. I have no doubt that moving the pit into the kernel is more efficient. Moving everything into the kernel is more efficient because light weight exits are cheaper than heavy weight exits. The thing I'm trying to get at is a quantitative statement about why moving the pit into the kernel is the right thing. I'll try to give the patches a try myself in the next couple of days. I don't think it's obvious that it's the right thing to do without some sort of benchmark supporting it. 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
On Tue, 2008-03-04 at 18:50 -0600, 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? It works. Just try to play a movie in windows standard HAL with and w/o -tdf --no-irq-chip and you'll see the difference. > > > 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? Play the same movie using the kernel's 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/vse012070mrt/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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
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 > Guest3min15s 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
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 Guest3min15s 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
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/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. 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/vse012070mrt/direct/01/ > >> ___ > >> kvm-devel mailing list > >> kvm-devel@lists.sourceforge.net > >> 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
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/vse012070mrt/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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
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. 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. 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/vse012070mrt/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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/6] In kernel PIT patch
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? Do you expect an overall performance improvement from this or is it simply about improving timer accuracy? 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/6] In kernel PIT patch
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. -- 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
