Message-ID: <20090213155507.GA2838@Krystal>
Date:	Fri, 13 Feb 2009 10:55:07 -0500
From:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	Bryan Wu <cooloney@...nel.org>, linux-kernel@...r.kernel.org,
	ltt-dev@...ts.casi.polymtl.ca,
	uclinux-dist-devel@...ckfin.uclinux.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [ltt-dev] [RFC git tree] Userspace RCU (urcu) for Linux
	(repost)

* Mathieu Desnoyers (compudj@...stal.dyndns.org) wrote:
> * Paul E. McKenney (paulmck@...ux.vnet.ibm.com) wrote:
> > On Sat, Feb 14, 2009 at 12:50:43AM +1100, Nick Piggin wrote:
> > > 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.
> > 
> > I have great sympathy for this point of view!!!  So why not have the
> > blackfin folks get the appropriate instructions added in the gcc port
> > to their architecture?  (Yeah, I know, gcc has no way of knowing which
> > variables are shared and not...)
> > 
> > But perhaps we could decorate the affected variable declarations with
> > a macro that expands to some sort of gcc attribute in the blackfin case?
> > 
> 
> I think that just for the fact that it help identifying such variable
> accesses which are :
> 
> - performed atomically
> - unprotected by any form of locking
> 
> This seems like a good things to wrap such accesses into a macro which
> permits easy identification of those sites. A bit like rcu_dereference()
> does. Gradual use of this new macro could come incrementally too.
> 

I created also

_STORE_SHARED()
_LOAD_SHARED()

which identify the variables which need to have cache flush done before
(load) or after (store). So we get both speed and identification when
needed (if we need to do batch updates linked with a single cache flush).
e.g.


/*
 * Identify a shared load. A smp_rmc() or smp_mc() should come before the load.
 */
#define _LOAD_SHARED(p)	       ACCESS_ONCE(p)

/*
 * Load a data from shared memory, doing a cache flush if required.
 */
#define LOAD_SHARED(p) \
	({ \
		smp_rmc(); \
		_LOAD_SHARED(p); \
	})


/*
 * Identify a shared store. A smp_wmc() or smp_mc() should follow the store.
 */
#define _STORE_SHARED(x, v) \
	do { \
		(x) = (v); \
	} while (0)

/*
 * Store v into x, where x is located in shared memory. Performs the required
 * cache flush after writing.
 */
#define STORE_SHARED(x, v) \
	do { \
		_STORE_SHARED(x, v); \
		smp_wmc(); \
	} while (0)

Mathieu

> Mathieu
> 
> 
> > 							Thanx, Paul
> > 
> > _______________________________________________
> > ltt-dev mailing list
> > ltt-dev@...ts.casi.polymtl.ca
> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> > 
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev@...ts.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
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/

Powered by blists - more mailing lists