From mboxrd@z Thu Jan  1 00:00:00 1970
From: mathieu.desnoyers@polymtl.ca (Mathieu Desnoyers)
Date: Mon, 14 Feb 2011 16:58:55 -0500
Subject: [ltt-dev] (forw) [rostedt@goodmis.org: Re: [PATCH 0/2] jump label:
	2.6.38	updates]
Message-ID: <BLU0-SMTP4D2EB21A8E0DAAD323FCB96D00@phx.gbl>

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