On Tue, Jul 31, 2012 at 4:59 PM, Josh Boyer <span dir="ltr"><<a href="mailto:jwboyer@gmail.com" target="_blank">jwboyer@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Jul 31, 2012 at 4:52 PM, Dan Allen <<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>> wrote:<br>
</div><div class="im">> Prior to kernel 3.4.7, libvirt was getting pinned to a single CPU after<br>
> resume (making VMs run painfully slow). This problem is documented<br>
> thoroughly in this BZ:<br>
><br>
> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=714271" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=714271</a><br>
><br>
> This problem is fixed in 3.4.7, which is currently waiting on karma in<br>
> Fedora 16. However, for Fedora 17, it's 3.5 that's in the queue (with -1<br>
> karma). Would it be possible to prepare 3.4.7 for Fedora 17 instead of 3.5<br>
> so that we get it sooner? This is really a painful bug.<br>
<br>
</div>No, but you don't need 3.4.7. The 3.5 update should already contain<br>
the same patch that fixed the libvirt issue. Specifically:<br>
<br>
CPU-hotplug-cpusets-suspend-Dont-modify-cpusets-during.patch<br>
<br>
which is definitely applied to the 3.5 F17 update.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>-Dan</div><div><br></div></div>-- <br><div>Dan Allen</div>Principal Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><div><a href="http://google.com/profiles/dan.j.allen" target="_blank">http://google.com/profiles/dan.j.allen</a><br>
<a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br></div><br>