Re: SMP syncronization on AMD processors (broken?)
From: Andrey Savochkin (saw_at_sawoct.com)
Date: Thu, 6 Oct 2005 19:21:06 +0400 To: Linus Torvalds <firstname.lastname@example.org>
On Thu, Oct 06, 2005 at 07:52:17AM -0700, Linus Torvalds wrote:
> On Thu, 6 Oct 2005, Andrey Savochkin wrote:
> > Well, it's hard to swallow...
> > It's not about being not fully fair, it's about deadlocks that started
> > to appear after code changes inside retry loops...
> No, it's not about fairness.
> It's about BUGS IN YOUR CODE.
> If you need fairness, you need to implement that yourself. You can do so
> many ways. Either on top of spinlocks, by using an external side-band
> channel, or by using semaphores instead of spinlocks (semaphores are much
> higher cost, but part of the cost is that they _are_ fair).
Ok, let it be a bug.
I just want to repeat that nobody wanted or expected any fairness in this case.
But such extremety that on some CPU models one CPU never, not in billion
cycles, can get the lock if the other CPU repeatedly drops and acquires the
lock, and that in this scenario memory changes seem to never propagate to
other CPUs - well, all of that is a surprise.
I start to wonder about existing mainstream code, presumably bug-free, that
uses spinlocks without any problematic restart.
If one day some piece starts to be called too often by some legitimate
reasons, it might fall into the same pattern and completely block others who
want to take the same spinlock.
I'm not advocating for changing spinlock implementation, it's just a
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/