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

[David Howells <dhowells@redhat.com>]

Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> Isn't the Alpha's split caches a counter-example of your model,
> because the coherency itself is out of order?

I'd forgotten I need to adjust my documentation to deal with this. It seems
this is the reason for read_barrier_depends(), and that read_barrier_depends()
is also a partial cache sync.

Do you know of any docs on Alpha's split caches? The Alpha Arch Handbook
doesn't say very much about cache operation on the Alpha.

I've looked around for what exactly is meant by "split cache" in conjunction
with Alpha CPUs, and I've found three different opinions of what it means:

 (1) Separate Data and Instruction caches.

 (2) Serial data caches (CPU -> L1 Cache -> L2 Cache -> L3 Cache -> Memory).

 (3) Parallel linked data caches, where a CPU's request can be satisfied by
     either data cache, in which whilst one data cache is being interrogated by
     the CPU, the other one can use the memory bus (at least, that's what I
     understand).

> Why do you need to include caches and queues in your model? Do
> programmers care? Isn't the following sufficient...

I don't think it is sufficient, given the number of times the way the cache
interacts with everything has come up in this discussion.

>          :    | m |
>    CPU -----> | e |
>          :    | m |
>          :    | o |
>    CPU -----> | r |
>          :    | y |
> 
> ... and bugger the implementation details?

Ah, but if the cache is on the CPU side of the dotted line, does that then mean
that a write memory barrier guarantees the CPU's cache to have updated memory?

David
-
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/