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

On Thu, 28 Jan 2016, Leonid Yegoshin wrote: > In http://patchwork.linux-mips.org/patch/10505/ the very last mesg exchange > is: [...] > ... and that stops forever... Thanks for the reminder -- last June was very hectic, I travelled a lot and I lost the discussion from my radar. Apologies for

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

On Wed, Jan 27, 2016 at 10:04:47AM +0800, Boqun Feng wrote: > On Tue, Jan 26, 2016 at 03:29:21PM -0800, Paul E. McKenney wrote: > > On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote: > > > On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds > > > wrote: > >

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

On Wed, Jan 27, 2016 at 10:25:46AM +, Will Deacon wrote: > On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote: > > On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote: > > > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > > > > On Mon, Jan 25, 2016 at

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

On 01/27/2016 03:26 AM, Maciej W. Rozycki wrote: On Fri, 15 Jan 2016, Leonid Yegoshin wrote: So you need to build a different kernel for some types of MIPS systems? Or do you do boot-time rewriting, like a number of other arches do? I don't know. I would like to have responses. Ralf asked

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

On 01/27/2016 03:26 AM, Maciej W. Rozycki wrote: On Fri, 15 Jan 2016, Leonid Yegoshin wrote: So you need to build a different kernel for some types of MIPS systems? Or do you do boot-time rewriting, like a number of other arches do? I don't know. I would like to have responses. Ralf asked

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

On Fri, 15 Jan 2016, Leonid Yegoshin wrote: > > So you need to build a different kernel for some types of MIPS systems? > > Or do you do boot-time rewriting, like a number of other arches do? > > I don't know. I would like to have responses. Ralf asked Maciej about old > systems and that came

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

On Wed, 27 Jan 2016, Ralf Baechle wrote: > > So you need to build a different kernel for some types of MIPS systems? > > Yes. We can't really do without. Classic MIPS code is not relocatable > without the complexity of PIC code as used by ELF DSOs - and their > performanc penalty. Plus we

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

On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote: > On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote: > > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > > > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote: > > > > On Fri, Jan 15, 2016 at

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

On Tue, Jan 26, 2016 at 12:13:39PM -0800, Paul E. McKenney wrote: > On Tue, Jan 26, 2016 at 11:19:27AM +0100, Peter Zijlstra wrote: > > So isn't smp_mb__after_unlock_lock() exactly such a scenario? And would > > not someone trying to implement RCsc locks using locally transitive > >

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

On Tue, Jan 26, 2016 at 03:37:33PM -0800, Paul E. McKenney wrote: > On Tue, Jan 26, 2016 at 12:10:10PM +, Will Deacon wrote: > > On Mon, Jan 25, 2016 at 05:06:46PM -0800, Paul E. McKenney wrote: > > > PPC WRCnf+addrs > > > "" > > > { > > > 0:r2=x; 0:r3=y; > > > 1:r2=x; 1:r3=y; > > > 2:r2=x;

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

On Thu, Jan 14, 2016 at 04:47:53PM -0800, Paul E. McKenney wrote: > So you need to build a different kernel for some types of MIPS systems? Yes. We can't really do without. Classic MIPS code is not relocatable without the complexity of PIC code as used by ELF DSOs - and their performanc

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

On Jan 26, 2016 23:51, "Peter Zijlstra" wrote: > > So for a moment it looked like MIPS wanted to equal or surpass Alpha in > this respect. If there is an architecture that I'd expect to try to take the "sucks more" crown, MIPS would be it. They've already done the "worst

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

On Mon, Jan 25, 2016 at 05:06:46PM -0800, Paul E. McKenney wrote: > On Mon, Jan 25, 2016 at 02:41:34PM +, Will Deacon wrote: > > On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote: > > > On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote: > > > > On Fri, Jan 15,

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

On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > specification (I seem to keep repeating this). > > Do we want this ? > > --- >

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

On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote: > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > > PPC Overlapping Group-B sets version 4 > > > "" > > > (* When the Group-B sets from two

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

On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote: > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > > On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote: > > > > Yes, that seems a

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

On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > > > >So SYNC_RMB is intended to implement smp_rmb(), correct? > > Yes. > > > > > >You could use

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

On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > specification (I seem to keep repeating this). Do we want this ? --- Documentation/memory-barriers.txt | 17 + 1 file changed, 17 insertions(+)

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

On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote: > If it turns out that some architecture does actually need a barrier > between a read and a dependent write, then that will mean that > > (a) we'll have to make up a _new_ barrier, because > "smp_read_barrier_depends()" is not

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

Hi Will, On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote: > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote: > > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > > > PPC

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

Hi Paul, On Mon, Jan 18, 2016 at 07:46:29AM -0800, Paul E. McKenney wrote: > On Mon, Jan 18, 2016 at 04:19:29PM +0800, Herbert Xu wrote: > > Paul E. McKenney wrote: > > > > > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > >

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

On Wed, Jan 27, 2016 at 12:52:07AM +0800, Boqun Feng wrote: > I recall that last time you and Linus came into a conclusion that even > on Alpha, a barrier for read->write with data dependency is unnecessary: > > http://article.gmane.org/gmane.linux.kernel/2077661 > > And in an earlier mail of

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

On Tue, Jan 26, 2016 at 9:22 AM, Peter Zijlstra wrote: > > This is distinct from: That may be distinct, but: > struct foo *x = READ_ONCE(*ptr); > smp_read_barrier_depends(); > x->bar = 5; This case is complete BS. Stop perpetuating it. I already

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

On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote: > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote: > > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > > > PPC Overlapping Group-B

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

On Tue, Jan 26, 2016 at 11:09:27AM +, Will Deacon wrote: > On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote: > > On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > > specification (I seem

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

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: > > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote: > > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > > > On Fri, Jan 15, 2016

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

On Wed, Jan 27, 2016 at 12:52:07AM +0800, Boqun Feng wrote: > Hi Paul, > > On Mon, Jan 18, 2016 at 07:46:29AM -0800, Paul E. McKenney wrote: > > On Mon, Jan 18, 2016 at 04:19:29PM +0800, Herbert Xu wrote: > > > Paul E. McKenney wrote: > > > > > > > > You could use

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

On Tue, Jan 26, 2016 at 11:44:46AM -0800, Linus Torvalds wrote: > On Tue, Jan 26, 2016 at 9:22 AM, Peter Zijlstra wrote: > > > > This is distinct from: > > That may be distinct, but: > > > struct foo *x = READ_ONCE(*ptr); > > smp_read_barrier_depends(); > >

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

On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > > > > > >So SYNC_RMB is intended to

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

On Tue, Jan 26, 2016 at 12:10 PM, Paul E. McKenney wrote: > On Tue, Jan 26, 2016 at 11:44:46AM -0800, Linus Torvalds wrote: >> >> > struct foo *x = READ_ONCE(*ptr); >> > smp_read_barrier_depends(); >> > x->bar = 5; >> >> This case is complete

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

On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds wrote: > > You might as well just write it as > > struct foo x = READ_ONCE(*ptr); > x->bar = 5; > > because that "smp_read_barrier_depends()" does NOTHING wrt the second write. Just to clarify: on alpha it

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

On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote: > On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds > wrote: > > > > You might as well just write it as > > > > struct foo x = READ_ONCE(*ptr); > > x->bar = 5; > > > > because that

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

On Tue, Jan 26, 2016 at 12:10:10PM +, Will Deacon wrote: > On Mon, Jan 25, 2016 at 05:06:46PM -0800, Paul E. McKenney wrote: > > On Mon, Jan 25, 2016 at 02:41:34PM +, Will Deacon wrote: > > > On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote: > > > > On Fri, Jan 15, 2016 at

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

On Tue, Jan 26, 2016 at 3:29 PM, Paul E. McKenney wrote: > > No trailing data-dependent read, so agreed, no smp_read_barrier_depends() > needed. That said, I believe that we should encourage rcu_dereference*() > or lockless_dereference() instead of READ_ONCE() for

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

On Tue, Jan 26, 2016 at 03:45:23PM -0800, Linus Torvalds wrote: > On Tue, Jan 26, 2016 at 3:29 PM, Paul E. McKenney > wrote: > > > > No trailing data-dependent read, so agreed, no smp_read_barrier_depends() > > needed. That said, I believe that we should encourage

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

On Tue, Jan 26, 2016 at 03:29:21PM -0800, Paul E. McKenney wrote: > On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote: > > On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds > > wrote: > > > > > > You might as well just write it as > > > > > > struct

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

On Mon, Jan 25, 2016 at 10:12:11PM -0800, Paul E. McKenney wrote: > On Mon, Jan 25, 2016 at 06:02:34PM +, Will Deacon wrote: > > Thanks for having a go at this. I tried defining something axiomatically, > > but got stuck pretty quickly. In my scheme, I used "data-directed > > transitivity"

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

On Mon, Jan 25, 2016 at 02:41:34PM +, Will Deacon wrote: > On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote: > > > On Fri, Jan 15, 2016 at 10:24:32AM +, Will Deacon wrote: > > > > See my earlier reply [1]

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

On Mon, Jan 25, 2016 at 06:02:34PM +, Will Deacon wrote: > Hi Paul, > > On Fri, Jan 15, 2016 at 09:39:12AM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote: > > > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > > > > So

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

On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote: > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote: > > > On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote: > > > > On Fri, Jan 15, 2016

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

On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote: > On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 10:24:32AM +, Will Deacon wrote: > > > See my earlier reply [1] (but also, your WRC Linux example looks more > > > like a variant on

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

On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote: > > On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote: > > > On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote: > > > > > > And the stuff

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

Hi Paul, On Fri, Jan 15, 2016 at 09:39:12AM -0800, Paul E. McKenney wrote: > On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote: > > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > > > So smp_mb() provides transitivity, as do pairs of smp_store_release() > > > and

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

On Mon, Jan 18, 2016 at 04:19:29PM +0800, Herbert Xu wrote: > Paul E. McKenney wrote: > > > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > > The reason for this is that

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

Paul E. McKenney wrote: > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > The reason for this is that smp_read_barrier_depends() must order the > pointer load against any

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

On Thu, Jan 14, 2016 at 02:55:10PM -0800, Paul E. McKenney wrote: > On Thu, Jan 14, 2016 at 01:36:50PM -0800, Leonid Yegoshin wrote: > > On 01/14/2016 01:29 PM, Paul E. McKenney wrote: > > > > > >>On 01/14/2016 12:34 PM, Paul E. McKenney wrote: > > >>> > > >>>The WRC+addr+addr is OK because data

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

On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote: > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > > So smp_mb() provides transitivity, as do pairs of smp_store_release() > > and smp_read_acquire(), > > But they provide different grades of transitivity, which

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

On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote: > On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote: > > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > > > So smp_mb() provides transitivity, as do pairs of smp_store_release() > > > and

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

On Fri, Jan 15, 2016 at 10:24:32AM +, Will Deacon wrote: > On Thu, Jan 14, 2016 at 02:55:10PM -0800, Paul E. McKenney wrote: > > On Thu, Jan 14, 2016 at 01:36:50PM -0800, Leonid Yegoshin wrote: > > > On 01/14/2016 01:29 PM, Paul E. McKenney wrote: > > > > > > > >>On 01/14/2016 12:34 PM, Paul

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

On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote: > On Fri, Jan 15, 2016 at 10:24:32AM +, Will Deacon wrote: > > On Thu, Jan 14, 2016 at 02:55:10PM -0800, Paul E. McKenney wrote: > > > On Thu, Jan 14, 2016 at 01:36:50PM -0800, Leonid Yegoshin wrote: > > > > On 01/14/2016 01:29

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

On 01/15/2016 01:57 AM, Will Deacon wrote: Paul, I think you figured this out while I was sleeping, but just to confirm: 1. The MIPS64 ISA doc [1] talks about SYNC in a way that applies only to memory accesses appearing in *program-order* before the SYNC 2. We need WRC+sync+addr to

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

On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote: > On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote: > > And the stuff we're confused about is how best to express the difference > > and guarantees of these two forms of transitivity and how exactly they > > interact.

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

On Fri, Jan 15, 2016 at 09:39:12AM -0800, Paul E. McKenney wrote: > Should we start putting litmus tests for the various examples > somewhere, perhaps in a litmus-tests directory within each participating > architecture? I have a pile of powerpc-related litmus tests on my laptop, > but they

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

On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote: > On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote: > > > > And the stuff we're confused about is how best to express the difference > > > and

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

On Fri, Jan 15, 2016 at 10:29:12PM +0100, Peter Zijlstra wrote: > On Fri, Jan 15, 2016 at 09:39:12AM -0800, Paul E. McKenney wrote: > > Should we start putting litmus tests for the various examples > > somewhere, perhaps in a litmus-tests directory within each participating > > architecture? I

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

On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > So smp_mb() provides transitivity, as do pairs of smp_store_release() > and smp_read_acquire(), But they provide different grades of transitivity, which is where all the confusion lays. smp_mb() is strongly/globally transitive,

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

On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote: > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > > So smp_mb() provides transitivity, as do pairs of smp_store_release() > > and smp_read_acquire(), > > But they provide different grades of transitivity, which

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

Paul, On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > It is not so simple, I mean "local ordering for address and data > > dependencies". Local ordering is NOT enough. It happens that current > > MIPS R6

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

On Thu, Jan 14, 2016 at 12:04:45PM +, Will Deacon wrote: > On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid Yegoshin wrote: > > On 01/13/2016 12:48 PM, Peter Zijlstra wrote: > > >On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote: > > > > > >>I ask HW team about it but I have a

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

On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: > And all that is out-of-topic here in my mind. I just want to be sure that > this patchset still provides a use of a specific lightweight SYNCs on MIPS > vs bold and heavy generalized "SYNC 0" in any case. > > - Leonid. Of course

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

On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid Yegoshin wrote: > On 01/13/2016 12:48 PM, Peter Zijlstra wrote: > >On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote: > > > >>I ask HW team about it but I have a question - has it any relationship with > >>replacing MIPS SYNC with

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

On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: > On 01/13/2016 02:45 AM, Will Deacon wrote: > >> > >I don't think the address dependency is enough on its own. By that > >reasoning, the following variant (WRC+addr+addr) would work too: > > > > > >P0: > >Wx = 1 > > > >P1: > >Rx ==

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

On Thu, Jan 14, 2016 at 01:36:50PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 01:29 PM, Paul E. McKenney wrote: > > > >>On 01/14/2016 12:34 PM, Paul E. McKenney wrote: > >>> > >>>The WRC+addr+addr is OK because data dependencies are not required to be > >>>transitive, in other words, they are

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

On 01/14/2016 02:24 PM, Paul E. McKenney wrote: Actually, the Linux kernel doesn't have an acquire barrier, just an smp_load_acquire(). Or did someone sneak one in while I wasn't looking? That was an exactly starting point for this discussion. This patch just pulls out from MIPS files

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

On Thu, Jan 14, 2016 at 01:45:44PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 01:34 PM, Paul E. McKenney wrote: > >On Thu, Jan 14, 2016 at 12:46:43PM -0800, Leonid Yegoshin wrote: > >>On 01/14/2016 12:15 PM, Peter Zijlstra wrote: > >>>On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin

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

On 01/14/2016 02:55 PM, Paul E. McKenney wrote: OK, so it looks like Will was asking not about WRC+addr+addr, but instead about WRC+sync+addr. (He actually asked twice about this and that too but skip this) I am guessing that the manual's "Older instructions which must be globally performed

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

On Thu, Jan 14, 2016 at 03:33:40PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 02:55 PM, Paul E. McKenney wrote: > >OK, so it looks like Will was asking not about WRC+addr+addr, but instead > >about WRC+sync+addr. > (He actually asked twice about this and that too but skip this) Fair enough!

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

On 01/14/2016 08:16 AM, Paul E. McKenney wrote: On Thu, Jan 14, 2016 at 12:04:45PM +, Will Deacon wrote: On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid Yegoshin wrote: On 01/13/2016 12:48 PM, Peter Zijlstra wrote: On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote: I ask

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

On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > >So SYNC_RMB is intended to implement smp_rmb(), correct? > Yes. > > > >You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > >smp_read_barrier_depends(), but

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

On 01/14/2016 04:47 PM, Paul E. McKenney wrote: On Thu, Jan 14, 2016 at 03:33:40PM -0800, Leonid Yegoshin wrote: Don't be fooled here by words "ordered" and "completed" - it is HW design items and actually written poorly. Just assume that SYNC_MB is absolutely the same as SYNC for any CPU and

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

On 01/14/2016 04:04 AM, Will Deacon wrote: Consequently, it's important that the architecture back-ends implement these portable primitives (e.g. smp_mb()) in a way that satisfies the kernel memory model so that core code doesn't need to worry about the underlying architecture for

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

On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > An the only point - please use an appropriate SYNC_* barriers instead of > heavy bold hammer. That stuff was design explicitly to support the > requirements of Documentation/memory-barriers.txt That's madness. That document

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

On 01/14/2016 12:48 PM, Paul E. McKenney wrote: So SYNC_RMB is intended to implement smp_rmb(), correct? Yes. You could use SYNC_ACQUIRE() to implement read_barrier_depends() and smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. If smp_read_barrier_depends() is used to

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

On Thu, Jan 14, 2016 at 01:01:05PM -0800, Leonid Yegoshin wrote: > I need some time to understand your test examples. However, Understood. > On 01/14/2016 12:34 PM, Paul E. McKenney wrote: > > > > > >The WRC+addr+addr is OK because data dependencies are not required to be > >transitive, in other

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

On Thu, Jan 14, 2016 at 12:46:43PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 12:15 PM, Peter Zijlstra wrote: > >On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > >>An the only point - please use an appropriate SYNC_* barriers instead of > >>heavy bold hammer. That stuff was

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

On 01/14/2016 01:29 PM, Paul E. McKenney wrote: On 01/14/2016 12:34 PM, Paul E. McKenney wrote: The WRC+addr+addr is OK because data dependencies are not required to be transitive, in other words, they are not required to flow from one CPU to another without the help of an explicit memory

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

On Thu, Jan 14, 2016 at 09:15:13PM +0100, Peter Zijlstra wrote: > On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > > An the only point - please use an appropriate SYNC_* barriers instead of > > heavy bold hammer. That stuff was design explicitly to support the > > requirements of

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

On 01/14/2016 12:15 PM, Peter Zijlstra wrote: On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: An the only point - please use an appropriate SYNC_* barriers instead of heavy bold hammer. That stuff was design explicitly to support the requirements of

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

On Thu, Jan 14, 2016 at 12:12:53PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 04:04 AM, Will Deacon wrote: > >Consequently, it's important that the architecture back-ends > >implement these portable primitives (e.g. smp_mb()) in a way that > >satisfies the kernel memory model so that core code

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

I need some time to understand your test examples. However, On 01/14/2016 12:34 PM, Paul E. McKenney wrote: The WRC+addr+addr is OK because data dependencies are not required to be transitive, in other words, they are not required to flow from one CPU to another without the help of an

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

On 01/14/2016 04:14 AM, Will Deacon wrote: On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: Moreover, there are voices against guarantee that it will be in future and that voices point me to Documentation/memory-barriers.txt section "DATA DEPENDENCY BARRIERS" examples

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

On Thu, Jan 14, 2016 at 11:28:18AM -0800, Leonid Yegoshin wrote: > On 01/14/2016 04:14 AM, Will Deacon wrote: > >On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: > > > >> Moreover, there are voices against guarantee that it will be in future > >>and that voices point me to

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

On Thu, Jan 14, 2016 at 09:15:13PM +0100, Peter Zijlstra wrote: > On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > > An the only point - please use an appropriate SYNC_* barriers instead of > > heavy bold hammer. That stuff was design explicitly to support the > > requirements of

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

On 01/14/2016 01:34 PM, Paul E. McKenney wrote: On Thu, Jan 14, 2016 at 12:46:43PM -0800, Leonid Yegoshin wrote: On 01/14/2016 12:15 PM, Peter Zijlstra wrote: On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: An the only point - please use an appropriate SYNC_* barriers instead

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

On Tue, Jan 12, 2016 at 12:45:14PM -0800, Leonid Yegoshin wrote: > >The issue I have with the SYNC description in the text above is that it > >describes the single CPU (program order) and the dual-CPU (confusingly > >named global order) cases, but then doesn't generalise any further. That > >means

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

On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote: > I ask HW team about it but I have a question - has it any relationship with > replacing MIPS SYNC with lightweight SYNCs (SYNC_WMB etc)? Of course. If you cannot explain the semantics of the primitives you introduce, how can we

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

On 01/13/2016 02:45 AM, Will Deacon wrote: On Tue, Jan 12, 2016 at 12:45:14PM -0800, Leonid Yegoshin wrote: I don't think the address dependency is enough on its own. By that reasoning, the following variant (WRC+addr+addr) would work too: P0: Wx = 1 P1: Rx == 1 Wy = 1 P2: Ry == 1 Rx =

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

On 01/13/2016 12:48 PM, Peter Zijlstra wrote: On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote: I ask HW team about it but I have a question - has it any relationship with replacing MIPS SYNC with lightweight SYNCs (SYNC_WMB etc)? Of course. If you cannot explain the semantics

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

On 01/13/2016 02:45 AM, Will Deacon wrote: I don't think the address dependency is enough on its own. By that reasoning, the following variant (WRC+addr+addr) would work too: P0: Wx = 1 P1: Rx == 1 Wy = 1 P2: Ry == 1 Rx = 0 So are you saying that this is also forbidden? Imagine that P0

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

On Mon, Jan 11, 2016 at 05:14:14PM -0800, Leonid Yegoshin wrote: > On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > >On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > >smp_read_barrier_depends, smp_store_release and smp_load_acquire match > >the asm-generic variants exactly. Drop

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

On Mon, Jan 11, 2016 at 05:14:14PM -0800, Leonid Yegoshin wrote: > This statement doesn't fit MIPS barriers variations. Moreover, there is a > reason to extend that even more specific, at least for smp_store_release and > smp_load_acquire, look into > >

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

On Tue, Jan 12, 2016 at 10:43:36AM +0200, Michael S. Tsirkin wrote: > On Mon, Jan 11, 2016 at 05:14:14PM -0800, Leonid Yegoshin wrote: > > On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > > >On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > > >smp_read_barrier_depends,

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

On Tue, Jan 12, 2016 at 11:40:12AM +0100, Peter Zijlstra wrote: > On Tue, Jan 12, 2016 at 11:25:55AM +0100, Peter Zijlstra wrote: > > On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > > > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > > > 0x12 semantics nor

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

On Tue, Jan 12, 2016 at 11:25:55AM +0100, Peter Zijlstra wrote: > On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > > 0x12 semantics nor does it provide a publicly accessible link to > > documentation that

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

On Tue, Jan 12, 2016 at 12:45:14PM -0800, Leonid Yegoshin wrote: > (I try to answer on multiple mails in one) > > First of all, it seems like some generic notes should be given here: > > 1. Generic MIPS "SYNC" (aka "SYNC 0") instruction is a very heavy in some > CPUs. On that CPUs it basically

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

On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > 0x12 semantics nor does it provide a publicly accessible link to > documentation that does. Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/

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

(I try to answer on multiple mails in one) First of all, it seems like some generic notes should be given here: 1. Generic MIPS "SYNC" (aka "SYNC 0") instruction is a very heavy in some CPUs. On that CPUs it basically kills pipelines in each CPU, can do a special memory/IO bus transaction

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

On 01/12/2016 01:40 PM, Peter Zijlstra wrote: It is selectable only for MIPS R2 but not MIPS R6. The reason is - most of MIPS R2 CPUs have short pipeline and that SYNC is just waste of CPU resource, especially taking into account that "lightweight syncs" are converted to a heavy "SYNC 0" in

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

On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, smp_read_barrier_depends, smp_store_release and smp_load_acquire match the asm-generic variants exactly. Drop the local definitions and pull in asm-generic/barrier.h instead. This