lkml.org 
[lkml]   [1999]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: New resources - pls, explain :-(
Alan Cox wrote:
> Store ordering below the compiler level is important. Doing
>
> foo[1]=1;
> foo[0]=2;
>
> May well be strictly ordered from the C point of view. What it looks like
> to another CPU or on another bus is entirely different to what ANSI says
> about the code within program flow.
>
> There are two layers of caches, write buffers on the cpu and the bridges
> and also inter cpu cache fill logic all conspiring to anooy you and all below
> the C world

Or in other words, on some systems special barrier instructions are
required to enforce readl/writel ordering at the bus level.

I know. What I mean is that in the following code, the compiler can put
`foo[1]=1' anywhere perfectly safely as long as it retains the ordering
of the writel() calls, and type aliasing allows this to be expressed.

writel(devaddr1, 2);
foo[1]=1;
writel(devaddr2, 3);

... but only if we don't define writel() to imply a memory barrier for
non-I/O bus accesses.

I think writel() and readl() should be serialised among themselves (and
other I/O primitives) at the bus level for the reasons already given by
others.

But there's no reason for readl/writel to serialise ordinary data
structure accesses. Where data structures require serialisation
(e.g. inter-CPU / interrupt) it's going to have to be explicit in the
code anyway (usually just a semaphore, spinlock or mb()), and may well
use different serialisation instructions or compiler constraints.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.037 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site