[ltt-dev] [Uclinux-dist-devel] [RFC git tree] Userspace RCU (urcu) for Linux (repost)

[Mike Frysinger]

On Fri, Feb 13, 2009 at 11:05, Linus Torvalds wrote:
> On Sat, 14 Feb 2009, Nick Piggin wrote:
>> Interesting. I don't know if you would say it is not cache coherent.
>> Does anything in cache coherency definition require timeliness? Only
>> causality I think.
>
> Nick, afaik, BF _really_ isn't cache coherent.
>
> It's not about timeliness. It's literally non-coherent.
>
> Blackfin L1 caches are
>  (a) write-through
>  (b) per-cpu
>  (c) non-coherent
> so the way that BF implements "cache coherency" is by literally
>
>  - use a magic test-and-set instruction that works on L2 memory (shared)
>  - keep track of which core has done that test-and-set last
>  - *flush* the L1 when it was the other core.
>
> Note that because it's a write-through cache, _writes_ are basically
> "coherent". But since the cache isn't actually _updated_ ont he other CPU,
> you can have two CPU's doing writes, and they'll both continue to see
> their own write, not necessarily the one that made it to memory. So I
> would not call that a "timeliness" issue, I would just say that the caches
> simply aren't coherent.
>
> But because it's write-through, flushing the cache always makes things
> coherent again (well, on _that_ CPU), of course.

it invalidates, not flushes, the cache when the lock changes hands.
and since the caches are forced to write through mode, the new core
should pick up all the correct data fresh from external memory.
-mike