Re: [PATCH] Another couple of alterations to the memory barrier doc

["Paul E. McKenney" <paulmck@us.ibm.com>]

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/