Messages in this thread |  | | | Date | Mon, 14 Feb 2011 15:19:45 -0800 | | From | "H. Peter Anvin" <> | | Subject | Re: [PATCH 0/2] jump label: 2.6.38 updates |
| |
On 02/14/2011 02:37 PM, Matt Fleming wrote: >> >> I don't see how cache coherency can possibly work if the hardware >> behaves this way. > > Cache coherency is still maintained provided writes/reads both go > through the cache ;-) > > The problem is that for read-modify-write operations the arbitration > logic that decides who "wins" and is allowed to actually perform the > write, assuming two or more CPUs are competing for a single memory > address, is not implemented in the cache controller, I think. I'm not a > hardware engineer and I never understood how the arbitration logic > worked but I'm guessing that's the reason that the ll/sc instructions > bypass the cache. > > Which is why the atomic_t functions worked out really well for that > arch, such that any accesses to an atomic_t * had to go through the > wrapper functions.
I'm sorry... this doesn't compute. Either reads can work normally (go through the cache) in which case atomic_read() can simply be a read or they don't, so I don't understand this at all.
-hpa
-- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
|  |