atom feed16 messages in org.freebsd.freebsd-smpRe: Matt's new unlock optimiazation
FromSent OnAttachments
Tommy HallgrenNov 23, 1999 5:39 am 
Peter WemmNov 23, 1999 6:01 am 
Poul-Henning KampNov 23, 1999 6:09 am 
Matthew DillonNov 23, 1999 9:02 am 
Matthew DillonNov 23, 1999 9:51 am 
Matthew DillonNov 23, 1999 10:18 am 
Matthew DillonNov 23, 1999 10:23 am 
Matthew DillonNov 23, 1999 10:23 am 
Alan CoxNov 23, 1999 10:38 am 
Matthew DillonNov 23, 1999 11:00 am 
Matthew DillonNov 23, 1999 11:41 am 
Matthew DillonNov 23, 1999 11:50 am 
Alfred PerlsteinNov 23, 1999 12:01 pm 
Alan CoxNov 23, 1999 12:22 pm 
Alan CoxNov 23, 1999 12:52 pm 
Alfred PerlsteinNov 23, 1999 1:09 pm 
Subject:Re: Matt's new unlock optimiazation
From:Alfred Perlstein (bri@wintelcom.net)
Date:Nov 23, 1999 12:01:39 pm
List:org.freebsd.freebsd-smp

On Tue, 23 Nov 1999, Matthew Dillon wrote:

:What Linus says is definitely true of non-x86 architectures, :such as Alpha, but I had thought (not to be confused with :"know for a fact") that the x86 was "sequentially :consistent", making Matt's optimization legal. : :I've definitely seen the statement in the Intel manuals :that writes are not reordered. Thus, if the :program on processor 1 writes X to location A followed :by Y to location B, then processor 2 is guaranteed to :see X in A (and not some old value) if it's seen Y in B.

Yes, that's what I thought too. Writes are not reordered, but remember that pentiums do speculative reads and out of order instruction execution as well. Apparently pentiums also do write buffering (rather then write to the cache synchronously).

http://developer.intel.com/drg/pentiumii/appnotes/831.htm

The above says:

* writes are ordered

* reads do not pass *conflicting* writes, which means they can pass non-conflicting writes. BROKEN!!!!!!!

* Instructions may execute out of order (if non conflicting)

* Writes can be buffered -- that is, the pending writes are pending going INTO the cache and not synchronously written to the cache as they are on, say, the later MIPS cpus.

What a grade-A screwup by Intel. Extremely annoying at the very least. Gimme a MIPS chip any day.

I'm a bit confused by this, I take it to mean that there's really nothing wrong with the lock behavior however, if there are outstanding memory transactions to handle then they may actually be done after we've released the lock by the CPU that's released it.

And that those memory operations rely on the mutual exclusion of the lock, so basically you have this sort of window:

CPU a (has lock) CPU b (wants lock)

mem write A mem read B mem write C RELEASE lock GOT lock

A, B C aren't garanteed to be complete at this point and could be committed to memory at any point following the lock release?

Is that correct?

-Alfred (who still needs his morning pot of coffee)

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message