You assume that spinlocks are the only reason a developer may want to yield the processor. This assumption is unfounded. Case in point - the primary backend in OpenLDAP uses a transactional database with page-level locking of its data structures to provide high levels of concurrency. It is the nature of such a system to encounter deadlocks over the normal course of operations. When a deadlock is detected, some thread must be chosen (by one of a variety of algorithms) to abort its transaction, in order to allow other operations to proceed to completion. In this situation, the chosen thread must get control of the CPU long enough to clean itself up, and then it must yield the CPU in order to allow any other competing threads to complete their transaction. The thread with the aborted transaction relinquishes all of its locks and then waits to get another shot at the CPU to try everything over again. Again, this is all fundamental to the nature of transactional programming. If the 2.6 kernel makes this programming model unreasonably slow, then quite simply this kernel is not viable as a database platform.