linux-kernel - Re: [ltt-dev] [RFC git tree] Userspace RCU (urcu) for Linux (repost)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 13 Feb 2009 08:05:06 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Nick Piggin <nickpiggin@...oo.com.au>
cc:	paulmck@...ux.vnet.ibm.com,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	ltt-dev@...ts.casi.polymtl.ca, linux-kernel@...r.kernel.org,
	Bryan Wu <cooloney@...nel.org>,
	uclinux-dist-devel@...ckfin.uclinux.org
Subject: Re: [ltt-dev] [RFC git tree] Userspace RCU (urcu) for Linux
 (repost)

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.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/