>>>>> "anton" == anton wilson <anton.wilson@camotion.com> writes: anton> On Wednesday 28 August 2002 12:41 pm, Jan Hudec wrote: >> On Tue, Aug 27, 2002 at 11:32:49AM -0700, Seth Arnold wrote: >> > On Tue, Aug 27, 2002 at 01:52:13PM -0400, anton wilson wrote: >> > > Does a volatile variable never reside in cache? >> > >> > It is my understanding of volatile that it will force the compiler to >> > never rely on a register for the value -- it must always fetch from >> > memory. The memory fetches will still go through cache. I think it is up >> > to the hardware to ensure that cache is coherent across all CPUs. >> >> As far as my understanding goes CPU will always cache it and caches will >> NOT be coherent between CPUs on many platforms. These platforms have an >> instruction that enforces the coherency at a given point. >> >> So volatile by itself gives nothing. In kernel you have to use barrier() >> macro (resp wmb() and rmb() macros). They both ensure CPU cache >> coherency and act as optimization barriers (cpu will not rely on >> register for any value across the barrier). anton> I was under the impression that the mb macros only prevent instructions after anton> the mb from occuring before the mb on processors that reorder instructions. Yes, but not "instructions", but "memory reads/writes". Also, memory barriers serving as a cache coherency mechanism is only partly true - they serve as an "completion" operation for the memory read/write, so cache coherency protocols are triggered. E.g. on PPC, after the "sync" insn, the previously initiated memory writes are performed with respect to all the other processors, i.e., other processors are able to change the state of a cache line from SHARED to INVALID. Before the "sync" insn, other CPUs (DMAs, busses, etc) may not even notice the memory write. ~velco -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
