Hi Jeff,
"Jeff V. Merkey" wrote:
<snip>
> If
> you used movb on some of Tricord's earlier SMP Systems, processors were
> not guaranteed to be granted the spinlock in a reasonable order,
> resulting in processes on one or more processors being endlessly locked
> spinning while other processors were always granted the lock first.
> With this optimization, if a spinlock is being used a lot, we may need
> to implement a "ticketing" algorithmn to ensure fairness in spinlock
> ordering, since on some systems, I have seen the movb unlock case cause
> fairness problems when several processors are all going after the same
> lock at the same time.
>
If you're willing to make the jump to a ticket-style lock, you should really look
at Anderson locks or MCS locks. I'm in the middle of a few different things now,
but the papers I've found seem to suggest much greater scalability than with
ticket locks.
Just my $0.02...
- Pete
>
> :-)
>
> Jeff
>
> Jamie Lokier wrote:
> >
> > Gérard Roudier wrote:
> > > I was not trying to defend Linus, but had questions in mind given than
> > > this topic had been discussed in _full_ details about one year ago (or
> > > more) and Linus had explained _clearly_ the reasons that let him take his
> > > decision at this time.
> >
> > Linus has changed his mind.
> >
> > It didn't happen until we restarted this thread, got some new tests done
> > and input from the right person at Intel.
> >
> > A small piece of code that occurs extremely often in the kernel just got
> > more than 20 times faster. Apparently it shows up in application
> > benchmarks.
> >
> > But even more importantly:
> >
> > We understand what's going on now!
> >
> > The older thread petered out with some loose ends. There were
> > conflicting conclusions and misunderstandings.
> >
> > Now, we understand that the faster code works with all Intel-style SMP
> > systems from Pentiums up, but may fail for some 386 or 486 SMP systems.
> > And we understand why.
> >
> > This is complex stuff and the folks writing the most basic code really
> > need to understand it. Why, only today, someone came to my office and
> > ask for an explanation of memory ordering problems between threads on an
> > SMP system. And I was able to refer to this thread. :-)
> >
> > have a nice day,
> > -- Jamie
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.rutgers.edu
> > Please read the FAQ at http://www.tux.org/lkml/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:14 EST