Messages in this thread | | | Date | Sun, 15 Aug 1999 02:12:36 +0200 | From | Jamie Lokier <> | Subject | Re: 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/
| |