lkml.org 
[lkml]   [2006]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2006-06-12 18:00    [W:0.064 / U:0.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site