On Thu, Jul 30, 2009 at 10:55:54AM +0800, Matthew Garrett wrote: > On Thu, Jul 30, 2009 at 10:43:00AM +0800, Shaohua Li wrote: > > On Thu, Jul 30, 2009 at 05:54:25AM +0800, Bjorn Helgaas wrote: > > > On some machines, a software-initiated SMI causes corruption unless the > > > SMI runs on CPU 0. An SMI can be initiated by any AML, but typically it's > > > done in GPE-related methods that are run via workqueues, so we can avoid > > > the known corruption cases by binding the workqueues to CPU 0. > > > > > > References: > > > http://bugzilla.kernel.org/show_bug.cgi?id=13751 > > > https://bugs.launchpad.net/bugs/157171 > > > https://bugs.launchpad.net/bugs/157691 > > Good job! Since any AML code can invoke a SMI, I wonder if all ACPICA should be > > limited to run on CPU 0? > > If ACPI is a performance bottleneck then we have other problems, so I > suspect that we could live with that. We'd probably want to be able to > disable it at runtime for the small number of users who have > "interesting" performance requirements, but falling on the side of > safety over slightly reduced latency under some circumstances seems fair > to me. It'd be interesting to see if this helps with any of the other > SMI-related hangs we've seeni. ACPICA isn't designed for performance. If it has performance issue, it should already have. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
