Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU after resume (making VMs run painfully slow). This problem is documented thoroughly in this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=714271
This problem is fixed in 3.4.7, which is currently waiting on karma in Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with -1 karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of 3.5 so that we get it sooner? This is really a painful bug.
-Dan
Actually, just getting 3.4.6-3 would be fine:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4325884
-Dan
On Tue, Jul 31, 2012 at 4:52 PM, Dan Allen dan.j.allen@gmail.com wrote:
Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU after resume (making VMs run painfully slow). This problem is documented thoroughly in this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=714271
This problem is fixed in 3.4.7, which is currently waiting on karma in Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with -1 karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of 3.5 so that we get it sooner? This is really a painful bug.
-Dan
-- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597
http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction
On Tue, Jul 31, 2012 at 4:52 PM, Dan Allen dan.j.allen@gmail.com wrote:
Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU after resume (making VMs run painfully slow). This problem is documented thoroughly in this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=714271
This problem is fixed in 3.4.7, which is currently waiting on karma in Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with -1 karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of 3.5 so that we get it sooner? This is really a painful bug.
No, but you don't need 3.4.7. The 3.5 update should already contain the same patch that fixed the libvirt issue. Specifically:
CPU-hotplug-cpusets-suspend-Dont-modify-cpusets-during.patch
which is definitely applied to the 3.5 F17 update.
josh
On Tue, Jul 31, 2012 at 4:59 PM, Josh Boyer jwboyer@gmail.com wrote:
On Tue, Jul 31, 2012 at 4:52 PM, Dan Allen dan.j.allen@gmail.com wrote:
Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU after resume (making VMs run painfully slow). This problem is documented thoroughly in this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=714271
This problem is fixed in 3.4.7, which is currently waiting on karma in Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with -1 karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of
3.5
so that we get it sooner? This is really a painful bug.
No, but you don't need 3.4.7. The 3.5 update should already contain the same patch that fixed the libvirt issue. Specifically:
CPU-hotplug-cpusets-suspend-Dont-modify-cpusets-during.patch
which is definitely applied to the 3.5 F17 update.
Hmm. My cpusets are still being modified. I'll reboot and run through the steps to verify I can reproduce it, then I'll report back.
-Dan
On Tue, Jul 31, 2012 at 4:59 PM, Josh Boyer jwboyer@gmail.com wrote:
On Tue, Jul 31, 2012 at 4:52 PM, Dan Allen dan.j.allen@gmail.com wrote:
Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU after resume (making VMs run painfully slow). This problem is documented thoroughly in this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=714271
This problem is fixed in 3.4.7, which is currently waiting on karma in Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with -1 karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of
3.5
so that we get it sooner? This is really a painful bug.
No, but you don't need 3.4.7. The 3.5 update should already contain the same patch that fixed the libvirt issue. Specifically:
CPU-hotplug-cpusets-suspend-Dont-modify-cpusets-during.patch
which is definitely applied to the 3.5 F17 update.
Oops, misunderstood your response the first time.
Yes, I agree the 3.5 update will have the same fix. I suggested 3.4.6-3 so that we can get the fix sooner since 3.5 seems to be stuck (due to a problem with cinnamon, according to the CI report).
(I am still seeing the issue with 3.4.6-2, which is what we would expect).
-Dan
On Tue, Jul 31, 2012 at 5:52 PM, Dan Allen dan.j.allen@gmail.com wrote:
On Tue, Jul 31, 2012 at 4:59 PM, Josh Boyer jwboyer@gmail.com wrote:
On Tue, Jul 31, 2012 at 4:52 PM, Dan Allen dan.j.allen@gmail.com wrote:
Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU after resume (making VMs run painfully slow). This problem is documented thoroughly in this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=714271
This problem is fixed in 3.4.7, which is currently waiting on karma in Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with -1 karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of 3.5 so that we get it sooner? This is really a painful bug.
No, but you don't need 3.4.7. The 3.5 update should already contain the same patch that fixed the libvirt issue. Specifically:
CPU-hotplug-cpusets-suspend-Dont-modify-cpusets-during.patch
which is definitely applied to the 3.5 F17 update.
Oops, misunderstood your response the first time.
Yes, I agree the 3.5 update will have the same fix. I suggested 3.4.6-3 so that we can get the fix sooner since 3.5 seems to be stuck (due to a problem with cinnamon, according to the CI report).
That karma is essentially worthless. There's no bug report for the issue. You're welcome to download the kernel from the update, install it, and give it positive karma if it works for you.
josh
On Tue, Jul 31, 2012 at 5:58 PM, Josh Boyer jwboyer@gmail.com wrote:
On Tue, Jul 31, 2012 at 5:52 PM, Dan Allen dan.j.allen@gmail.com wrote:
On Tue, Jul 31, 2012 at 4:59 PM, Josh Boyer jwboyer@gmail.com wrote:
On Tue, Jul 31, 2012 at 4:52 PM, Dan Allen dan.j.allen@gmail.com
wrote:
Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU
after
resume (making VMs run painfully slow). This problem is documented thoroughly in this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=714271
This problem is fixed in 3.4.7, which is currently waiting on karma in Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with
-1
karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of 3.5 so that we get it sooner? This is really a painful bug.
No, but you don't need 3.4.7. The 3.5 update should already contain the same patch that fixed the libvirt issue. Specifically:
CPU-hotplug-cpusets-suspend-Dont-modify-cpusets-during.patch
which is definitely applied to the 3.5 F17 update.
Oops, misunderstood your response the first time.
Yes, I agree the 3.5 update will have the same fix. I suggested 3.4.6-3
so
that we can get the fix sooner since 3.5 seems to be stuck (due to a
problem
with cinnamon, according to the CI report).
That karma is essentially worthless. There's no bug report for the issue. You're welcome to download the kernel from the update, install it, and give it positive karma if it works for you.
Ah, gotcha.
In fact, I just downloaded the kernel from koji and installed it between replies :) Everything is working great, including the preservation of the cpuset value after resume.
Karma given.
-Dan
-
Dan Allen -
Josh Boyer