On Wed, 7 Mar 2007, Jean Delvare wrote: > On Tue, 6 Mar 2007 21:40:19 +0100 (CET), Bodo Eggert wrote: > > 1) I asume port allocations or ACPI foreign port acces to be rare, so > > there would be little impact on (un)registering hardware. Off cause > > there are some long ACPI calls (like reading the battery?), in these > > cases it might be beneficial to release the global allocation lock > > after gaining exclusive access to the driver's port range. (This can > > only be done if the device driver is loaded.) > > The problem is that the rarity of ACPI foreign port access doesn't > matter much, as you have to do all the tests first to find out that it > was a foreign port, and I suspect that these tests will cost more than > taking the lock itself. Testing for the internal ranges can be done by searching a list of about five ranges, that should be not much slower than taking an uncontended lock, and very much faster than waiting for smbus to finish it's current task in case the lock is contended. I'm more concerned about driver (un)loading being slowed down by ACPI. [...] > We may be able to workaround the inter-driver exclusion though, if we > use a semaphore initialized to N, have ACPI take N, but other drivers > take just one. This would let ACPI be exclusive with all the other > drivers, but drivers themselves could otherwise run concurrently. That > being said, we do not appear to have the required primitives to take > more than 1 semaphore resource at once at the moment, so we'd need to > do that first. worst case I can imagine: IDE/graphic stalles while ACPI takes a second to read the battery state. -- Top 100 things you don't want the sysadmin to say: 82. Where's the DIR command? - 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
