Messages in this thread | | | Date | Mon, 12 Jun 2006 08:58:34 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH] Another couple of alterations to the memory barrier doc |
| |
On Mon, Jun 12, 2006 at 11:42:11AM +0100, David Howells wrote: > > The attached patch makes another couple of alterations to the memory barrier > document following suggestions by Alan Stern and in co-operation with Paul > McKenney: > > (*) Rework the point of introduction of memory barriers and the description > of what they are to reiterate why they're needed. > > (*) Modify a statement about the use of data dependency barriers to note that > other barriers can be used instead (as they imply DD-barriers).
Good stuff!
Thanx, Paul
Acked-By: Paul E. McKenney <paulmck@us.ibm.com> > Signed-Off-By: David Howells <dhowells@redhat.com> > --- > warthog>diffstat -p1 /tmp/mb.diff > Documentation/memory-barriers.txt | 15 ++++++++++----- > 1 file changed, 10 insertions(+), 5 deletions(-) > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index 4710845..cc53f47 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -262,9 +262,14 @@ What is required is some way of interven > CPU to restrict the order. > > Memory barriers are such interventions. They impose a perceived partial > -ordering between the memory operations specified on either side of the barrier. > -They request that the sequence of memory events generated appears to other > -parts of the system as if the barrier is effective on that CPU. > +ordering over the memory operations on either side of the barrier. > + > +Such enforcement is important because the CPUs and other devices in a system > +can use a variety of tricks to improve performance - including reordering, > +deferral and combination of memory operations; speculative loads; speculative > +branch prediction and various types of caching. Memory barriers are used to > +override or suppress these tricks, allowing the code to sanely control the > +interaction of multiple CPUs and/or devices. > > > VARIETIES OF MEMORY BARRIER > @@ -461,8 +466,8 @@ Whilst this may seem like a failure of c > isn't, and this behaviour can be observed on certain real CPUs (such as the DEC > Alpha). > > -To deal with this, a data dependency barrier must be inserted between the > -address load and the data load: > +To deal with this, a data dependency barrier or better must be inserted > +between the address load and the data load: > > CPU 1 CPU 2 > =============== =============== - 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/
| |