linux-kernel - Re: [Uclinux-dist-devel] [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]

Message-ID: <8bd0f97a0902131911m7c06fbe8nb83f12f740bd7997@mail.gmail.com>
Date:	Fri, 13 Feb 2009 22:11:26 -0500
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	linux-kernel@...r.kernel.org, ltt-dev@...ts.casi.polymtl.ca,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	uclinux-dist-devel@...ckfin.uclinux.org, paulmck@...ux.vnet.ibm.com
Subject: Re: [Uclinux-dist-devel] [ltt-dev] [RFC git tree] Userspace RCU 
	(urcu) for Linux (repost)

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
--
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/