Thread (152 messages) 152 messages, 13 authors, 2016-04-14

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

From: Paul E. McKenney <hidden>
Date: 2016-01-26 22:00:45
Also in: linux-arch, linux-arm-kernel, linux-s390, linux-sh, linux-um, linuxppc-dev, lkml, sparclinux, virtualization

On Tue, Jan 26, 2016 at 11:19:27AM +0100, Peter Zijlstra wrote:
On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote:
quoted
On Mon, Jan 25, 2016 at 04:42:43PM +0000, Will Deacon wrote:
quoted
On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote:
quoted
On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote:
quoted
quoted
quoted
quoted
Yes, that seems a good start. But yesterday you raised the 'fun' point
of two globally ordered sequences connected by a single local link.
The conclusion that I am slowly coming to is that litmus tests should
not be thought of as linear chains, but rather as cycles.  If you think
of it as a cycle, then it doesn't matter where the local link is, just
how many of them and how they are connected.
Do you have some examples of this? I'm struggling to make it work in my
mind, or are you talking specifically in the context of the kernel
memory model?
Now that you mention it, maybe it would be best to keep the transitive
and non-transitive separate for the time being anyway.  Just because it
might be possible to deal with does not necessarily mean that we should
be encouraging it.  ;-)
So isn't smp_mb__after_unlock_lock() exactly such a scenario? And would
not someone trying to implement RCsc locks using locally transitive
RELEASE/ACQUIRE operations need exactly this stuff?

That is, I am afraid we need to cover the mix of local and global
transitive operations at least in overview.
True, but we haven't gotten to locking yet.  That said, I would argue
that smp_mb__after_unlock_lock() upgrades locks to transitive, and
thus would not be an exception to the "no combining transitive and
non-transitive steps in cycles" rule.

							Thanx, Paul
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help