Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Nov 1999 11:01:00 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Alan Cox <alc@cs.rice.edu>
Cc:        Poul-Henning Kamp <phk@critter.freebsd.dk>, Peter Wemm <peter@netplex.com.au>, Tommy Hallgren <thallgren@yahoo.com>, freebsd-smp@FreeBSD.ORG
Subject:   Re: Matt's new unlock optimiazation
Message-ID:  <199911231901.LAA10726@apollo.backplane.com>
References:  <19991123140128.3A7D41C6D@overcee.netplex.com.au> <28648.943366199@critter.freebsd.dk> <19991123123846.E20514@cs.rice.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
: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.

    In anycase, I've committed the change.  It only adds 50ns or so to 
    the release code and then only on the final release.

    The app note says:

    * Locked operations wait for all previous instructions to complete.
      They wait for on-chip buffers to drain, and for external buffers to
      be emptied.

    * Locked operations synchronize data, but not instruction fetch or 
      TLB miss handling.  Data may be present in a cache or TLB, due
      to the speculative cacheability feature, which means that a lock
      cannot be used to prevent data from being fetched into a cache or
      TLB.

    I believe this does what we want.  In regards to the last bit, since
    the cache is operating under SMP protocols the speculative read into
    the cache should be ok as long as the cpu's buffers have been drained,
    which they have been.

						-Matt



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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911231901.LAA10726>