[ltt-dev] (forw) [rostedt at goodmis.org: Re: [PATCH 0/2] jump label: 2.6.38 updates]

[Mathieu Desnoyers]

I'm also thinking that the combination of rcu_cmpxchg_pointer() and
rcu_dereference() are problematic, because we use ll/sc for the cmpxchg
without the matching lwz on the read-side. We should probably also use a
matching stw for rcu_assign_pointer if we want to support this case.

Mathieu

* Mathieu Desnoyers (mathieu.desnoyers at polymtl.ca) wrote:
> Hi Paul,
> 
> Please see the message below. It looks like the liburcu
> uatomic_read()/uatomic_set() implementations would need to be moved to
> lwz/stw if what Steven says below is true. It seems to be in sync with
> what is done in the libatomic ops implementation.
> 
> Thoughts ?
> 
> Mathieu
> 
> ----- Forwarded message from Steven Rostedt <rostedt at goodmis.org> -----
> 
> Date: Mon, 14 Feb 2011 16:39:36 -0500
> To: Peter Zijlstra <peterz at infradead.org>
> Cc: Will Newton <will.newton at gmail.com>, Jason Baron <jbaron at redhat.com>,
> 	Mathieu Desnoyers <mathieu.desnoyers at polymtl.ca>, hpa at zytor.com,
> 	mingo at elte.hu, tglx at linutronix.de, andi at firstfloor.org,
> 	roland at redhat.com, rth at redhat.com, masami.hiramatsu.pt at hitachi.com,
> 	fweisbec at gmail.com, avi at redhat.com, davem at davemloft.net,
> 	sam at ravnborg.org, ddaney at caviumnetworks.com, michael at ellerman.id.au,
> 	linux-kernel at vger.kernel.org, Mike Frysinger <vapier at gentoo.org>,
> 	Chris Metcalf <cmetcalf at tilera.com>, dhowells <dhowells at redhat.com>,
> 	Martin Schwidefsky <schwidefsky at de.ibm.com>,
> 	"heiko.carstens" <heiko.carstens at de.ibm.com>,
> 	benh <benh at kernel.crashing.org>
> X-Mailer: Evolution 2.30.3 
> From: Steven Rostedt <rostedt at goodmis.org>
> Subject: Re: [PATCH 0/2] jump label: 2.6.38 updates
> 
> On Mon, 2011-02-14 at 16:29 -0500, Steven Rostedt wrote:
> 
> > > while (atomic_read(&foo) != n)
> > >   cpu_relax();
> > > 
> > > and the problem is that cpu_relax() doesn't know which particular
> > > cacheline to flush in order to make things go faster, hm?
> > 
> > But what about any global variable? Can't we also just have:
> > 
> > 	while (global != n)
> > 		cpu_relax();
> > 
> > ?
> 
> Matt Fleming answered this for me on IRC, and I'll share the answer here
> (for those that are dying to know ;)
> 
> Seems that the atomic_inc() uses ll/sc operations that do not affect the
> cache. Thus the problem is only with atomic_read() as
> 
> 	while(atomic_read(&foo) != n)
> 		cpu_relax();
> 
> Will just check the cache version of foo. But because ll/sc skips the
> cache, the foo will never update. That is, atomic_inc() and friends do
> not touch the cache, and the CPU spinning in this loop will is only
> checking the cache, and will spin forever.
> 
> Thus it is not about global, as global is updated by normal means and
> will update the caches. atomic_t is updated via the ll/sc that ignores
> the cache and causes all this to break down. IOW... broken hardware ;)
> 
> Matt, feel free to correct this if it is wrong.
> 
> -- Steve
> 
> -- 
> Mathieu Desnoyers
> Operating System Efficiency R&D Consultant
> EfficiOS Inc.
> http://www.efficios.com

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com