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