On Thu, 21 Jun 2007 10:31:53 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > On Thu, 21 Jun 2007, Chuck Ebbert wrote: > > > > A while ago I showed that spinlocks were a lot more fair when doing > > unlock with the xchg instruction on x86. Probably the arbitration is all > > screwed up because we use a mov instruction, which while atomic is not > > locked. > > No, the cache line arbitration doesn't know anything about "locked" vs > "unlocked" instructions (it could, but there really is no point). > > The real issue is that locked instructions on x86 are serializing, which > makes them extremely slow (compared to just a write), and then by being > slow they effectively just make the window for another core bigger. > This reminds me Nick's proposal of 'queued spinlocks' 3 months ago Maybe this should be re-considered ? (unlock is still a non atomic op, so we dont pay the serializing cost twice) http://lwn.net/Articles/227506/ extract : Implement queued spinlocks for i386. This shouldn't increase the size of the spinlock structure, while still able to handle 2^16 CPUs. The queued spinlock has 2 fields, a head and a tail, which are indexes into a FIFO of waiting CPUs. To take a spinlock, a CPU performs an "atomic_inc_return" on the head index, and keeps the returned value as a ticket. The CPU then spins until the tail index is equal to that ticket. To unlock a spinlock, the tail index is incremented (this can be non atomic, because only the lock owner will modify tail). Implementation inefficiencies aside, this change should have little effect on performance for uncontended locks, but will have quite a large cost for highly contended locks [O(N) cacheline transfers vs O(1) per lock aquisition, where N is the number of CPUs contending]. The benefit is is that contended locks will not cause any starvation. Just an idea. Big NUMA hardware seems to have fairness logic that prevents starvation for the regular spinlock logic. But it might be interesting for -rt kernel or systems with starvation issues. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
