User: Password:
Subscribe / Log in / New account

Concurrency-managed workqueues

Concurrency-managed workqueues

Posted Oct 8, 2009 14:16 UTC (Thu) by nix (subscriber, #2304)
Parent article: Concurrency-managed workqueues

The ACPI code had bound a workqueue thread to CPU 0 because some operations corrupt the system if run anywhere else
Is this just BIOSes being their usual malevolently incompetent selves, or is there a rational reason for this requirement? Because my first impression when reading this was 'WTF WTF WTF'...

(Log in to post comments)

Concurrency-managed workqueues

Posted Oct 8, 2009 14:27 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

On some HPs, at least, certain ACPI operations trigger SMIs that then appear to be run on the CPU that triggered the SMI. HP's SMI handler seems to fail to restore CPU state if it runs on anything other than CPU 0.

Concurrency-managed workqueues

Posted Oct 8, 2009 17:16 UTC (Thu) by mebrown (subscriber, #7960) [Link]

This is also true for Dell SMI implementation, so I'd assume that this is widely true or some kind of limitation of SMI. If you trigger a SMI from any CPU other than CPU #0, you get all kinds of interesting fireworks and possibly random memory locations overwritten.

Concurrency-managed workqueues

Posted Oct 9, 2009 10:02 UTC (Fri) by nix (subscriber, #2304) [Link]

Ah. SMI. Malevolently incompetent by default, then. :/

(ACPI triggering SMI. What a nice way to take a kernel-controls-all VM executor and throw you into the undefeined-behaviour swamp again. Sigh.)

Concurrency-managed workqueues

Posted Oct 19, 2009 0:13 UTC (Mon) by vonbrand (guest, #4458) [Link]

"Simply Malevolently Incompetent"?

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds