Messages in this thread | | | Date | Thu, 21 Jun 2007 13:14:52 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [BUG] long freezes on thinkpad t60 |
| |
On Thu, 21 Jun 2007, Ingo Molnar wrote: > > * Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > If somebody can actually come up with a sequence where we have > > spinlock starvation, and it's not about an example of bad locking, and > > nobody really can come up with any other way to fix it, we may > > eventually have to add the notion of "fair spinlocks". > > there was one bad case i can remember: the spinlock debugging code had a > trylock open-coded loop and on certain Opterons CPUs were starving each > other.
But this is a perfect example of exactly what I'm talking about:
THAT CODE IS HORRIBLY BUGGY!
It's not the spinlocks that are broken, it's that damn code.
> for (;;) { > for (i = 0; i < loops; i++) { > if (__raw_write_trylock(&lock->raw_lock)) > return; > __delay(1); > }
What a piece of crap.
Anybody who ever waits for a lock by busy-looping over it is BUGGY, dammit!
The only correct way to wait for a lock is:
(a) try it *once* with an atomic r-m-w (b) loop over just _reading_ it (and something that implies a memory barrier, _not_ "__delay()". Use "cpu_relax()" or "smp_rmb()") (c) rinse and repeat.
and code like the above should just be shot on sight.
So don't blame the spinlocks or the hardware for crap code.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |