In fact, I would go so far as to say that we ought to get everything working perfectly on Linux using existing semaphores and spinlocks before we even think about converting to mutexes - unless there still is no simple timeout mechanism available for semaphores on Linux. > -----Original Message----- > From: Moore, Robert > Sent: Thursday, June 01, 2006 3:04 PM > To: Brown, Len > Cc: 'linux-acpi@xxxxxxxxxxxxxxx' > Subject: RE: ACPI locking > > I would say that we should fix the issues at hand before we even think > about fussing with the ACPI CA interfaces -- as this always seems to break > things as well. > > It is ok to change the ACPICA interfaces, but other operating systems > should get a vote in this also. There is also the documentation and other > testing overhead to consider also. > > As I've said, the goal has been to minimize the number of OSL/ACPICA > interfaces in order to have the smallest number of interfaces to provide > the required functionality. Just because an OS provides a dozen different > ways to allocate memory doesn't mean that we need that many OSL > interfaces. Indeed, the future plan for all hosts is to remove the OSL and > replace it with native OS calls anyway. > > That said, I would say that the locking and multithreading issues can get > complex enough, we should get it working 1000% correct before we think > about optimizing interfaces. > > Bob > > > > -----Original Message----- > > From: Brown, Len > > Sent: Thursday, June 01, 2006 2:51 PM > > To: Moore, Robert > > Cc: 'linux-acpi@xxxxxxxxxxxxxxx' > > Subject: RE: ACPI locking > > > > > > >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
