>It has been a while since we have looked at the ACPICA locking >stuff, and I suppose now is as good a time as any. I am also >concerned with the Linux-only implementation and deployment of >the OsWaitEventsComplete interface, in terms of how the >locking interacts with it. (I am also concerned with why only >Linux has requested this interface.) I don't know why other OSs don't need acpi_os_wait_events_complete(). Maybe they don't do any deferred processing. But in any case, that is a different issue than the (simpler) one at hand. >The historical note on the OSL semaphore interfaces is that we >felt that if a "mutex" object was available in the host OS, it >could be used for the case where the OsCreateSemaphore() call >specified a MaxUnits parameter of one (a binary semaphore) - >rather than having an entirely separate "mutex" OSL interface. >The OSL spinlock interfaces were added later and are currently >only used in a limited way. Of course, when the day comes that >the ACPICA code is fully integrated into the host OS, the OSL >interfaces will probably be replaced by native OS calls, so we >always thought of the OSL interface as a somewhat interim >oil-slick, therefore we wanted to minimize the number of >different interfaces to it. Linux just recently added dedicated mutex entry points to optimize the case where semaphores were used a mutexes. We can take advantate of the acpi_os_create_semaphore() trick without changing the ACPICA interface, but the problem is that the actual lock/unlock entry points are now different for mutexes and semaphores and would have to be handled at run-time. So if ACPICA wants a mutex, it would be best if it asked for one directly and used mutex entry/exit points too. On an OS where mutexes and semaphores are the same, the OSL can (continue to) map them to the same create/lock/unlock routines. More interesting is if ACPICA actually only needs a spin-lock. The key semantic from the Linux side is that spin-locks can be called at interrupt context and can not be held for sleeping. On the other hand, mutexes and semaphores can NOT be invoked from interrupt context precicely because they DO support sleeping. It would be nice if the ACPICA/OS interface can encode those choices and the OS can choose the appropriate types of locks to use. >3) The list of global mutexes should be looked at. I suspect >that a couple of them are obsolete and not used or could be >merged with another. As far as spinlock vs. mutex, we >certainly may be able to replace some mutexes with spinlocks, >but certainly not all. The best example of where a mutex is >required would be the Interpreter mutex, another example would >be the Namespace mutex where we need to lock the namespace >while possibly extensive allocations take place during a >dynamic table load. Where we could possibly use a spinlock is >to replace the ACPI hardware mutex. Agreed. hardware mutex looks perfect for a spin-lock, and the others which involve memory allocation look like they want a mutex. Unclear that anything needs an actual counting semaphore. Looks like there are a couple that allocate a semaphore as locked by playing with the intial value, maybe these are really just mutexes too? >5.1) We may be able to delete the units parameter for >OsWaitSemaphore, it's just there to match Signal. We use the >units parameter with signal during global lock operations. > >5.2) As far as the semaphore timeout code in the Linux OSL >implementation, it is my understanding that this >polled-timeout code was written because (at least at the >time), Linux did not have a convenient interface to allow a >semaphore wait for a specific amount of time. It is clearly >very bad and should go away ASAP. Yeah, the polling scheme looks like an invitation to starvation. I think the solution is probably something like... Set up a timeout() on the maximum duration and invoke mutex_lock_interruptable(). If the timeout expires, the handler sends a signal to break the locked task out of mutex_lock_interruptable(). If the task gets the lock, then cancel the timeout. I'd imagine that there must be someplace else in the kernel that wants a mutex with a timeout, but a quick look and I don't see this scheme elsewhere, so maybe there is a simpler way? > Also, now that Linux has >mutex interfaces in addition to semaphore interfaces, it would >be best to migrate the use of binary semaphores to mutexes in >the Linux OSL. The init is easy. The question is if you want to look up in a list on every lock/unlock the type of lock you have. I think the answer is no, and that the code should ask for the appropriate init/lock/unlock for the 3 types of locks that are available: 1. spin lock that can be at interrupt context, but can sleep with it 2. mutex that can sleep, but illegal at interupt context 3. counting semaphore that can sleep, but illegal at interrupt context >Hopefully, the new mutex interfaces in Linux >allow a simple timeout, that may remove the need for a timeout >on a semaphore wait entirely. I don't think the timeout on semaphore wait is the biggest problem here. The biggest problem is the lack of clarity between locks that can be called at interrupt level and locks that can sleep. I think that distinction needs to be in the ACPICA/OS interface. The semaphore with timeout appears to be only needed to execute ASL Acquire(). While it has to work and it would be nice if it were efficient and starvation and delay resistant, in practice it probably executes far less frequently than the other simple locks in the code which should be implemented in the most efficient way possible. cheers, -Len - 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
