On Wed, Jun 8, 2011 at 12:17 PM, Ingo Molnar <mingo@xxxxxxx> wrote: > > Hm, the no-wakeup aspect seems rather useful. I like the patch, but I would like to get it much better abstracted out. Make some kind of void atomic_down(); int atomic_down_trylock(); void atomic_up(); interfaces that basically get the semaphore in an "atomic" mode that leaves the semaphore spinlock locked in the locked region. So they would basically be spinlocks that can then be mixed with normal sleeping semaphore usage. > Could we perhaps remove console_sem and replace it with a mutex and > do something like this with a mutex and its ->wait_lock? That would be horrible. The reason it works well for semaphores is that the semaphores have no architecture-specific fast-path any more, and everything is done within the spinlock. With a mutex? Not good. We have several different mutex implementations, along with fastpaths that never touch the spinlock at all etc. And that is very much on purpose, because the spinlock approach is noticeably slower and needs more atomic accesses. In contrast, the semaphores are "legacy interfaces" and aren't considered high-performance locking any more. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html