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

[Nick Piggin]

On Friday 13 February 2009 08:59:59 Paul E. McKenney wrote:
> On Thu, Feb 12, 2009 at 01:15:08PM -0800, Linus Torvalds wrote:
> > On Thu, 12 Feb 2009, Paul E. McKenney wrote:
> > > In other words, you are arguing for using ACCESS_ONCE() in the loops,
> > > but keeping the old ACCESS_ONCE() definition, and declaring BF hardware
> > > broken?
> >
> > Well, I _also_ argue that if you have a busy loop, you'd better have a
> > cpu_relax() in there somewhere anyway. If you don't, you have a bug.
> >
> > So I think the BF approach is "borderline broken", but I think it should
> > work, if BF just has whatever appropriate cache flush in its cpu_relax.
>
> OK, got it.  Keep ACCESS_ONCE() as is, make sure any busy-wait
> loops contain a cpu_relax().  A given busy loop might or might not
> need ACCESS_ONCE(), but that decision is independent of hardware
> considerations.
>
> Ah, and blackfin's cpu_relax() does seem to have migrated from barrier()
> to smp_mb() recently, so sounds good to me!!!


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.

However I think "infinite write buffering delay", or requiring "cache
barriers" is insane to teach any generic code about. BF would be free
to optimise arch functions, but for correctness surely it must also
have a periodic interrupt that will expose stores to other CPUs.