Re: [PATCH] Document Linux's memory barriers [try #5]

[Nick Piggin <nickpiggin@yahoo.com.au>]

Linus Torvalds wrote:

> Well, the argument I have against mentioning caches is that cache 
> coherency order is _not_ the only thing that is relevant. As already 
> mentioned, data speculation can cause exactly the same "non-causal" effect 
> as cache update ordering, so from a _conceptual_ standpoint, the cache is 
> really just one implementation detail in the much bigger picture of 
> buffering and speculative work re-ordering operations...
> 

Agreed. I wonder how you can best illustrate the theoretical machine
model (from a programmer's point of view). I guess each consistency
domain has an horizon (barrier, but I'm trying to avoid that word in
this context) over which memory barriers will provide some partial
ordering on transactions going to and/or from the horizon.

            +---+   :   |c
            |CPU|---:---|a m
            +---+   :   |c e
                    :   |h m
            +---+   :   |e o
            |CPU|---:---|d r
            +---+   :   |  y

I guess you could think of a smp_wmb() in this case being a wall that
moves out from the CPU along with other memory stores, and stops them
from passing (the problem with a "wall" is that it doesn't easily apply
to a full smp_mb() unless you have loads travelling the same way, which
has its own intuitiveness problems).

> So it might be a good idea to first explain the memory barriers in a more 
> abstract sense without talking about what exactly goes on, and then have 
> the section that gives _examples_ of what the CPU actually is doing that 
> causes these barriers to be needed. And make it clear that the examples 
> are just that - examples.
> 

Yeah that would be nice. The abstract explanation will be tricky. Maybe
it isn't so critical to be easily understandable if it is backed by
examples.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com