On Tue, Feb 09, 2016 at 12:23:58PM +0100, Ingo Molnar wrote:
> * Will Deacon wrote:
> > On Wed, Feb 03, 2016 at 01:32:10PM +, Will Deacon wrote:
> > > On Wed, Feb 03, 2016 at 09:33:39AM +0100, Ingo Molnar wrote:
> > > > In fact I'd suggest to test this via a quick runtime hack like this in
>
* Will Deacon wrote:
> On Wed, Feb 03, 2016 at 01:32:10PM +, Will Deacon wrote:
> > On Wed, Feb 03, 2016 at 09:33:39AM +0100, Ingo Molnar wrote:
> > > In fact I'd suggest to test this via a quick runtime hack like this in
> > > rcupdate.h:
> > >
> > > extern int panic_timeout;
> > >
> >
On Tue, Feb 02, 2016 at 11:55:57AM -0800, Linus Torvalds wrote:
> On Tue, Feb 2, 2016 at 11:30 AM, Will Deacon wrote:
> >
> > FWIW, and this is by no means conclusive, I hacked that up quickly and
> > ran hackbench a few times on the nearest idle arm64 system. The results
> > were consistently ~4%
On Wed, Feb 03, 2016 at 01:32:10PM +, Will Deacon wrote:
> On Wed, Feb 03, 2016 at 09:33:39AM +0100, Ingo Molnar wrote:
> > In fact I'd suggest to test this via a quick runtime hack like this in
> > rcupdate.h:
> >
> > extern int panic_timeout;
> >
> > ...
> >
> > if (panic_time
On Wed, Feb 03, 2016 at 09:33:39AM +0100, Ingo Molnar wrote:
> * Will Deacon wrote:
> > On Tue, Feb 02, 2016 at 10:06:36AM -0800, Linus Torvalds wrote:
> > > On Tue, Feb 2, 2016 at 9:51 AM, Will Deacon wrote:
> > > >
> > > > Given that the vast majority of weakly ordered architectures respect
> >
* Will Deacon wrote:
> On Tue, Feb 02, 2016 at 10:06:36AM -0800, Linus Torvalds wrote:
> > On Tue, Feb 2, 2016 at 9:51 AM, Will Deacon wrote:
> > >
> > > Given that the vast majority of weakly ordered architectures respect
> > > address dependencies, I would expect all of them to be hurt if the
On Tue, Feb 02, 2016 at 06:23:37PM +0100, Peter Zijlstra wrote:
>
>
> On 2 February 2016 07:44:33 CET, "Paul E. McKenney"
> wrote:
>
> >
> >> If so, do we also need to take the following pairing into
> >consideration?
> >>
> >> o smp_store_release() -> READ_ONCE(); if ;smp_rmb();
>
>
> We
On Tue, Feb 02, 2016 at 09:56:14AM -0800, Linus Torvalds wrote:
> On Tue, Feb 2, 2016 at 4:02 AM, Paul E. McKenney
> wrote:
> >
> > The sorts of things I am really worried about are abominations like this
> > (and far worse):
>
> That one doesn't have any causal chain that I can see, so I agree t
On Tue, Feb 2, 2016 at 11:30 AM, Will Deacon wrote:
>
> FWIW, and this is by no means conclusive, I hacked that up quickly and
> ran hackbench a few times on the nearest idle arm64 system. The results
> were consistently ~4% slower using acquire for rcu_dereference.
Ok, that's *much* more noticea
On Tue, Feb 02, 2016 at 10:06:36AM -0800, Linus Torvalds wrote:
> On Tue, Feb 2, 2016 at 9:51 AM, Will Deacon wrote:
> >
> > Given that the vast majority of weakly ordered architectures respect
> > address dependencies, I would expect all of them to be hurt if they
> > were forced to use barrier i
On Tue, Feb 2, 2016 at 9:51 AM, Will Deacon wrote:
>
> Given that the vast majority of weakly ordered architectures respect
> address dependencies, I would expect all of them to be hurt if they
> were forced to use barrier instructions instead, even those where the
> microarchitecture is fairly st
On Tue, Feb 2, 2016 at 4:02 AM, Paul E. McKenney
wrote:
>
> The sorts of things I am really worried about are abominations like this
> (and far worse):
That one doesn't have any causal chain that I can see, so I agree that
it's an abomination, but it also doesn't act as an argument.
> r1 == 1 &
On Tue, Feb 02, 2016 at 09:30:26AM -0800, Linus Torvalds wrote:
> On Tue, Feb 2, 2016 at 1:34 AM, Boqun Feng wrote:
> >
> > Just to be clear, what Will, Paul and I are discussing here is about
> > local transitivity,
>
> I really don't think that changes the picture.
For the general point about
On Tue, Feb 02, 2016 at 09:12:37AM -0800, Paul E. McKenney wrote:
> On Tue, Feb 02, 2016 at 12:20:25PM +, Will Deacon wrote:
> > On Tue, Feb 02, 2016 at 08:12:30PM +0800, Boqun Feng wrote:
> > > On Tue, Feb 02, 2016 at 11:45:59AM +, Will Deacon wrote:
> > > > Well, the following ISA2 test i
On Tue, Feb 2, 2016 at 1:34 AM, Boqun Feng wrote:
>
> Just to be clear, what Will, Paul and I are discussing here is about
> local transitivity,
I really don't think that changes the picture.
Given that
(a) we already mix ordering methods and there are good reasons for
it, and I'd expect trans
On 2 February 2016 07:44:33 CET, "Paul E. McKenney"
wrote:
>
>> If so, do we also need to take the following pairing into
>consideration?
>>
>> osmp_store_release() -> READ_ONCE(); if ;smp_rmb();
We rely on this with smp_cond_aquire() to extend the chain.
--
Sent from my Android devic
On Tue, Feb 02, 2016 at 12:20:25PM +, Will Deacon wrote:
> On Tue, Feb 02, 2016 at 08:12:30PM +0800, Boqun Feng wrote:
> > On Tue, Feb 02, 2016 at 11:45:59AM +, Will Deacon wrote:
> > > On Tue, Feb 02, 2016 at 01:19:04PM +0800, Boqun Feng wrote:
> > > > On Mon, Feb 01, 2016 at 07:54:58PM -0
Ralf Baechle writes:
> On Tue, Feb 02, 2016 at 02:54:06PM +, Måns Rullgård wrote:
>
>> We don't really have much choice given the reality of existing hardware.
>
> No, of course not - but I want us discourage new weakly ordered
> platforms as much as possible.
Where do you draw the line thou
On Tue, Feb 02, 2016 at 02:54:06PM +, Måns Rullgård wrote:
> We don't really have much choice given the reality of existing hardware.
No, of course not - but I want us discourage new weakly ordered
platforms as much as possible.
Ralf
Ralf Baechle writes:
> On Tue, Feb 02, 2016 at 12:19:04AM -0800, Linus Torvalds wrote:
>
>> Memory ordering is confusing enough as it is. We should not make
>> people worry more than they already have to. Strong rules are good.
>
> Confusing and the resulting bugs can be very hard to debug.
>
> O
On Tue, Feb 02, 2016 at 12:19:04AM -0800, Linus Torvalds wrote:
> Memory ordering is confusing enough as it is. We should not make
> people worry more than they already have to. Strong rules are good.
Confusing and the resulting bugs can be very hard to debug.
One of the problems I've experience
On Tue, Feb 02, 2016 at 12:20:25PM +, Will Deacon wrote:
[...]
> > > >
> > > > Besides, Will, what's the reason of having a locally transitive chain
> > > > termination? Because on some architectures RELEASE->DEPENDENCY pairs may
> > > > not be locally transitive?
> > >
> > > Well, the follow
On Tue, Feb 02, 2016 at 08:12:30PM +0800, Boqun Feng wrote:
> On Tue, Feb 02, 2016 at 11:45:59AM +, Will Deacon wrote:
> > On Tue, Feb 02, 2016 at 01:19:04PM +0800, Boqun Feng wrote:
> > > On Mon, Feb 01, 2016 at 07:54:58PM -0800, Paul E. McKenney wrote:
> > > > On Mon, Feb 01, 2016 at 01:56:22
On Tue, Feb 02, 2016 at 11:45:59AM +, Will Deacon wrote:
> On Tue, Feb 02, 2016 at 01:19:04PM +0800, Boqun Feng wrote:
> > On Mon, Feb 01, 2016 at 07:54:58PM -0800, Paul E. McKenney wrote:
> > > On Mon, Feb 01, 2016 at 01:56:22PM +, Will Deacon wrote:
> > > > On Fri, Jan 29, 2016 at 02:22:5
On Tue, Feb 02, 2016 at 12:19:04AM -0800, Linus Torvalds wrote:
> On Tue, Feb 2, 2016 at 12:07 AM, Linus Torvalds
> wrote:
> >
> > So we *absolutely* should say that *OF COURSE* these things work:
> >
> > - CPU A:
> >
> >.. initialize data structure -> smp_wmb() -> WRITE_ONCE(ptr);
> >
> > -
On Tue, Feb 02, 2016 at 01:19:04PM +0800, Boqun Feng wrote:
> On Mon, Feb 01, 2016 at 07:54:58PM -0800, Paul E. McKenney wrote:
> > On Mon, Feb 01, 2016 at 01:56:22PM +, Will Deacon wrote:
> > > On Fri, Jan 29, 2016 at 02:22:53AM -0800, Paul E. McKenney wrote:
> > > > On Fri, Jan 29, 2016 at 09
Hello Linus,
On Tue, Feb 02, 2016 at 12:19:04AM -0800, Linus Torvalds wrote:
> On Tue, Feb 2, 2016 at 12:07 AM, Linus Torvalds
> wrote:
> >
> > So we *absolutely* should say that *OF COURSE* these things work:
> >
> > - CPU A:
> >
> >.. initialize data structure -> smp_wmb() -> WRITE_ONCE(pt
On Tue, Feb 2, 2016 at 12:07 AM, Linus Torvalds
wrote:
>
> So we *absolutely* should say that *OF COURSE* these things work:
>
> - CPU A:
>
>.. initialize data structure -> smp_wmb() -> WRITE_ONCE(ptr);
>
> - CPU B:
>
>smp_load_acquire(ptr) - we can rely on things behind "ptr" being
>
On Mon, Feb 1, 2016 at 10:44 PM, Paul E. McKenney
wrote:
> On Tue, Feb 02, 2016 at 01:19:04PM +0800, Boqun Feng wrote:
>> Hi Paul,
>> If so, do we also need to take the following pairing into consideration?
>>
>> o smp_store_release() -> READ_ONCE(); if ;smp_rmb();
>
> It looks like we will b
On Tue, Feb 02, 2016 at 01:19:04PM +0800, Boqun Feng wrote:
> Hi Paul,
>
> On Mon, Feb 01, 2016 at 07:54:58PM -0800, Paul E. McKenney wrote:
> > On Mon, Feb 01, 2016 at 01:56:22PM +, Will Deacon wrote:
> > > On Fri, Jan 29, 2016 at 02:22:53AM -0800, Paul E. McKenney wrote:
> > > > On Fri, Jan
Hi Paul,
On Mon, Feb 01, 2016 at 07:54:58PM -0800, Paul E. McKenney wrote:
> On Mon, Feb 01, 2016 at 01:56:22PM +, Will Deacon wrote:
> > On Fri, Jan 29, 2016 at 02:22:53AM -0800, Paul E. McKenney wrote:
> > > On Fri, Jan 29, 2016 at 09:59:59AM +, Will Deacon wrote:
> > > > On Thu, Jan 28,
On Mon, Feb 01, 2016 at 01:56:22PM +, Will Deacon wrote:
> On Fri, Jan 29, 2016 at 02:22:53AM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 29, 2016 at 09:59:59AM +, Will Deacon wrote:
> > > On Thu, Jan 28, 2016 at 02:31:31PM -0800, Paul E. McKenney wrote:
> >
> > [ . . . ]
> >
> > > > F
On Fri, Jan 29, 2016 at 02:22:53AM -0800, Paul E. McKenney wrote:
> On Fri, Jan 29, 2016 at 09:59:59AM +, Will Deacon wrote:
> > On Thu, Jan 28, 2016 at 02:31:31PM -0800, Paul E. McKenney wrote:
>
> [ . . . ]
>
> > > For Linux in general, this is a question: How strict do we want to be
> > >
On Fri, Jan 29, 2016 at 09:59:59AM +, Will Deacon wrote:
> On Thu, Jan 28, 2016 at 02:31:31PM -0800, Paul E. McKenney wrote:
[ . . . ]
> > For Linux in general, this is a question: How strict do we want to be
> > about matching the type of write with the corresponding read? My
> > default ap
Hi Paul,
On Thu, Jan 28, 2016 at 02:31:31PM -0800, Paul E. McKenney wrote:
> On Thu, Jan 28, 2016 at 09:57:19AM +, Will Deacon wrote:
> > On Wed, Jan 27, 2016 at 03:38:36PM -0800, Paul E. McKenney wrote:
> > > On Wed, Jan 27, 2016 at 03:21:58PM +, Will Deacon wrote:
> > Yes, sorry for the
On Thu, Jan 28, 2016 at 09:57:19AM +, Will Deacon wrote:
> On Wed, Jan 27, 2016 at 03:38:36PM -0800, Paul E. McKenney wrote:
> > On Wed, Jan 27, 2016 at 03:21:58PM +, Will Deacon wrote:
> > > On Wed, Jan 27, 2016 at 03:54:21PM +0100, Peter Zijlstra wrote:
> > > > On Wed, Jan 27, 2016 at 11:
On Wed, Jan 27, 2016 at 03:38:36PM -0800, Paul E. McKenney wrote:
> On Wed, Jan 27, 2016 at 03:21:58PM +, Will Deacon wrote:
> > On Wed, Jan 27, 2016 at 03:54:21PM +0100, Peter Zijlstra wrote:
> > > On Wed, Jan 27, 2016 at 11:43:48AM +, Will Deacon wrote:
> > > > Do you know whether a SYNC
Hi Maciej,
On Wed, Jan 27, 2016 at 12:41:29PM +, Maciej W. Rozycki wrote:
> On Wed, 27 Jan 2016, Will Deacon wrote:
>
> > > Overall I think it should be safe after all to use SYNC_RELEASE and
> > > other
> > > modern lightweight barriers uncondtionally under the assumption that
> > > arch
On Wed, Jan 27, 2016 at 03:21:58PM +, Will Deacon wrote:
> On Wed, Jan 27, 2016 at 03:54:21PM +0100, Peter Zijlstra wrote:
> > On Wed, Jan 27, 2016 at 11:43:48AM +, Will Deacon wrote:
> > > Do you know whether a SYNC 18 (RELEASE) followed in program order by a
> > > SYNC 17 (ACQUIRE) create
On Wed, Jan 27, 2016 at 03:54:21PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 27, 2016 at 11:43:48AM +, Will Deacon wrote:
> > Do you know whether a SYNC 18 (RELEASE) followed in program order by a
> > SYNC 17 (ACQUIRE) creates a full barrier (i.e. something like SYNC 16)?
> >
> > If not, you
On Wed, Jan 27, 2016 at 11:43:48AM +, Will Deacon wrote:
> Do you know whether a SYNC 18 (RELEASE) followed in program order by a
> SYNC 17 (ACQUIRE) creates a full barrier (i.e. something like SYNC 16)?
>
> If not, you may need to implement smp_mb__after_unlock_lock for RCU
> to ensure global
On Wed, 27 Jan 2016, Will Deacon wrote:
> > Overall I think it should be safe after all to use SYNC_RELEASE and other
> > modern lightweight barriers uncondtionally under the assumption that
> > architecture was meant to remain backward compatible. Even though it
> > might be possible someone
Hi Maciej,
Thanks for digging all this up.
On Wed, Jan 27, 2016 at 09:57:24AM +, Maciej W. Rozycki wrote:
> On Thu, 12 Nov 2015, David Daney wrote:
>
> > > > Certainly we can load up the code with "SYNC" all over the place, but
> > > > it will kill performance on SMP systems. So, my vote wo
On Thu, 12 Nov 2015, David Daney wrote:
> > > Certainly we can load up the code with "SYNC" all over the place, but
> > > it will kill performance on SMP systems. So, my vote would be to make
> > > it as light weight as possible, but no lighter. That will mean
> > > inventing the proper barrier
On 11/12/2015 10:13 AM, Måns Rullgård wrote:
David Daney writes:
On 11/12/2015 04:31 AM, Peter Zijlstra wrote:
Hi
I think the MIPS arch_spin_unlock() is borken.
spin_unlock() must have RELEASE semantics, these require that no LOADs
nor STOREs leak out from the critical section.
From what
David Daney writes:
> On 11/12/2015 04:31 AM, Peter Zijlstra wrote:
>> Hi
>>
>> I think the MIPS arch_spin_unlock() is borken.
>>
>> spin_unlock() must have RELEASE semantics, these require that no LOADs
>> nor STOREs leak out from the critical section.
>>
>> From what I know MIPS has a relaxed
On Thu, Nov 12, 2015 at 09:46:53AM -0800, David Daney wrote:
> For CONFIG_CPU_CAVIUM_OCTEON the proper thing would be:
>
> smp_wmb();
> smp_rmb();
>
> Which expands to exactly the same thing as wmb() because smp_rmb() expands
> to nothing.
OK, so the current code isn't broken because fo
On 11/12/2015 04:31 AM, Peter Zijlstra wrote:
Hi
I think the MIPS arch_spin_unlock() is borken.
spin_unlock() must have RELEASE semantics, these require that no LOADs
nor STOREs leak out from the critical section.
From what I know MIPS has a relaxed memory model which allows reads to
pass sto
On Thu, Nov 12, 2015 at 02:50:00PM +, Måns Rullgård wrote:
> "Paul E. McKenney" writes:
>
> > On Thu, Nov 12, 2015 at 01:31:23PM +0100, Peter Zijlstra wrote:
> >> Hi
> >>
> >> I think the MIPS arch_spin_unlock() is borken.
> >>
> >> spin_unlock() must have RELEASE semantics, these require t
"Paul E. McKenney" writes:
> On Thu, Nov 12, 2015 at 01:31:23PM +0100, Peter Zijlstra wrote:
>> Hi
>>
>> I think the MIPS arch_spin_unlock() is borken.
>>
>> spin_unlock() must have RELEASE semantics, these require that no LOADs
>> nor STOREs leak out from the critical section.
>>
>> >From wha
On Thu, Nov 12, 2015 at 01:31:23PM +0100, Peter Zijlstra wrote:
> Hi
>
> I think the MIPS arch_spin_unlock() is borken.
>
> spin_unlock() must have RELEASE semantics, these require that no LOADs
> nor STOREs leak out from the critical section.
>
> >From what I know MIPS has a relaxed memory mode
Peter Zijlstra writes:
> Hi
>
> I think the MIPS arch_spin_unlock() is borken.
>
> spin_unlock() must have RELEASE semantics, these require that no LOADs
> nor STOREs leak out from the critical section.
>
> From what I know MIPS has a relaxed memory model which allows reads to
> pass stores, and
On Thu, Nov 12, 2015 at 01:31:23PM +0100, Peter Zijlstra wrote:
> +++ b/arch/mips/include/asm/spinlock.h
> @@ -140,7 +140,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
> static inline void arch_spin_unlock(arch_spinlock_t *lock)
> {
> unsigned int serving_now = lock->h.servi
Hi
I think the MIPS arch_spin_unlock() is borken.
spin_unlock() must have RELEASE semantics, these require that no LOADs
nor STOREs leak out from the critical section.
>From what I know MIPS has a relaxed memory model which allows reads to
pass stores, and as implemented arch_spin_unlock() only
54 matches
Mail list logo
