Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH] Document Linux's memory barriers [try #4] | Date | Wed, 15 Mar 2006 11:10:18 +0000 |
| |
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/
| |