Re: [PATCH] documentation: Fix two-CPU control-dependency example

On Wed, Jul 19, 2017 at 02:56:02PM -0700, Paul E. McKenney wrote: > On Thu, Jul 20, 2017 at 06:33:26AM +0900, Akira Yokosawa wrote: > > On 2017/07/20 2:43, Paul E. McKenney wrote: > > > On Mon, Jul 17, 2017 at 05:24:42PM +0900, Akira Yokosawa wrote: > > >> >From

Re: [PATCH] documentation: Fix two-CPU control-dependency example

On Wed, Jul 19, 2017 at 02:56:02PM -0700, Paul E. McKenney wrote: > On Thu, Jul 20, 2017 at 06:33:26AM +0900, Akira Yokosawa wrote: > > On 2017/07/20 2:43, Paul E. McKenney wrote: > > > On Mon, Jul 17, 2017 at 05:24:42PM +0900, Akira Yokosawa wrote: > > >> >From

Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document

On Mon, Jun 12, 2017 at 04:49:29PM +0200, Peter Zijlstra wrote: [...] > -Any atomic operation that modifies some state in memory and returns > information > -about the state (old or new) implies an SMP-conditional general memory > barrier > -(smp_mb()) on each side of the actual operation (with

Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document

On Mon, Jun 12, 2017 at 04:49:29PM +0200, Peter Zijlstra wrote: [...] > -Any atomic operation that modifies some state in memory and returns > information > -about the state (old or new) implies an SMP-conditional general memory > barrier > -(smp_mb()) on each side of the actual operation (with

Re: [PATCH 10/17] RISC-V: Atomic and Locking Code

On Wed, Jul 12, 2017 at 08:40:49PM +0800, Boqun Feng wrote: [...] > > +/** > > + * set_bit - Atomically set a bit in memory > > + * @nr: the bit to set > > + * @addr: the address to start counting from > > + * > > + * This function is atomic and

Re: [PATCH 10/17] RISC-V: Atomic and Locking Code

On Wed, Jul 12, 2017 at 08:40:49PM +0800, Boqun Feng wrote: [...] > > +/** > > + * set_bit - Atomically set a bit in memory > > + * @nr: the bit to set > > + * @addr: the address to start counting from > > + * > > + * This function is atomic and

Re: [PATCH 10/17] RISC-V: Atomic and Locking Code

On Tue, Jul 11, 2017 at 06:31:23PM -0700, Palmer Dabbelt wrote: [...] > diff --git a/arch/riscv/include/asm/bitops.h b/arch/riscv/include/asm/bitops.h > new file mode 100644 > index ..b0a0c76e966a > --- /dev/null > +++ b/arch/riscv/include/asm/bitops.h > @@ -0,0 +1,216 @@ > +/* > + *

Re: [PATCH 10/17] RISC-V: Atomic and Locking Code

On Tue, Jul 11, 2017 at 06:31:23PM -0700, Palmer Dabbelt wrote: [...] > diff --git a/arch/riscv/include/asm/bitops.h b/arch/riscv/include/asm/bitops.h > new file mode 100644 > index ..b0a0c76e966a > --- /dev/null > +++ b/arch/riscv/include/asm/bitops.h > @@ -0,0 +1,216 @@ > +/* > + *

Re: [PATCH 2/9] RISC-V: Atomic and Locking Code

On Thu, Jul 06, 2017 at 06:04:13PM -0700, Palmer Dabbelt wrote: [...] > >> +#define __smp_load_acquire(p) > >> \ > >> +do { > >> \ > >> + union { typeof(*p) __val; char __c[1]; } __u

Re: [PATCH 2/9] RISC-V: Atomic and Locking Code

On Thu, Jul 06, 2017 at 06:04:13PM -0700, Palmer Dabbelt wrote: [...] > >> +#define __smp_load_acquire(p) > >> \ > >> +do { > >> \ > >> + union { typeof(*p) __val; char __c[1]; } __u

Re: [PATCH 2/9] RISC-V: Atomic and Locking Code

On Wed, Jul 05, 2017 at 10:43:21AM +0200, Peter Zijlstra wrote: > On Tue, Jul 04, 2017 at 12:50:55PM -0700, Palmer Dabbelt wrote: > > +/* > > + * FIXME: I could only find documentation that atomic_{add,sub,inc,dec} are > > + * barrier-free. I'm assuming that and/or/xor have the same constraints

Re: [PATCH 2/9] RISC-V: Atomic and Locking Code

On Wed, Jul 05, 2017 at 10:43:21AM +0200, Peter Zijlstra wrote: > On Tue, Jul 04, 2017 at 12:50:55PM -0700, Palmer Dabbelt wrote: > > +/* > > + * FIXME: I could only find documentation that atomic_{add,sub,inc,dec} are > > + * barrier-free. I'm assuming that and/or/xor have the same constraints

Re: [PATCH 2/9] RISC-V: Atomic and Locking Code

On Tue, Jul 04, 2017 at 12:50:55PM -0700, Palmer Dabbelt wrote: [...] > diff --git a/arch/riscv/include/asm/cmpxchg.h > b/arch/riscv/include/asm/cmpxchg.h > new file mode 100644 > index ..81025c056412 > --- /dev/null > +++ b/arch/riscv/include/asm/cmpxchg.h > @@ -0,0 +1,138 @@ > +/* >

Re: [PATCH 2/9] RISC-V: Atomic and Locking Code

On Tue, Jul 04, 2017 at 12:50:55PM -0700, Palmer Dabbelt wrote: [...] > diff --git a/arch/riscv/include/asm/cmpxchg.h > b/arch/riscv/include/asm/cmpxchg.h > new file mode 100644 > index ..81025c056412 > --- /dev/null > +++ b/arch/riscv/include/asm/cmpxchg.h > @@ -0,0 +1,138 @@ > +/* >

Re: [PATCH RFC 21/26] powerpc: Remove spin_unlock_wait() arch-specific definitions

.ozlabs.org> > Cc: Will Deacon <will.dea...@arm.com> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Alan Stern <st...@rowland.harvard.edu> > Cc: Andrea Parri <parri.and...@gmail.com> > Cc: Linus Torvalds <torva...@linux-foundation.org> Acked

Re: [PATCH RFC 21/26] powerpc: Remove spin_unlock_wait() arch-specific definitions

-specific > arch_spin_unlock_wait(). > > Signed-off-by: Paul E. McKenney > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: > Cc: Will Deacon > Cc: Peter Zijlstra > Cc: Alan Stern > Cc: Andrea Parri > Cc: Linus Torvalds Acked-by: Boqun

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Thu, Jun 29, 2017 at 09:02:41PM -0700, Paul E. McKenney wrote: [...] > > > o net/netfilter/nf_conntrack_core.c nf_conntrack_lock() > > > This instance of spin_unlock_wait() interacts with > > > nf_conntrack_all_lock()'s instance of spin_unlock_wait(). > > > Although

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Thu, Jun 29, 2017 at 09:02:41PM -0700, Paul E. McKenney wrote: [...] > > > o net/netfilter/nf_conntrack_core.c nf_conntrack_lock() > > > This instance of spin_unlock_wait() interacts with > > > nf_conntrack_all_lock()'s instance of spin_unlock_wait(). > > > Although

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Thu, Jun 29, 2017 at 11:11:26AM -0700, Paul E. McKenney wrote: > On Thu, Jun 29, 2017 at 11:59:27AM -0400, Alan Stern wrote: > > On Thu, 29 Jun 2017, Will Deacon wrote: > > > > > [turns out I've not been on cc for this thread, but Jade pointed me to it > > > and I see my name came up at some

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Thu, Jun 29, 2017 at 11:11:26AM -0700, Paul E. McKenney wrote: > On Thu, Jun 29, 2017 at 11:59:27AM -0400, Alan Stern wrote: > > On Thu, 29 Jun 2017, Will Deacon wrote: > > > > > [turns out I've not been on cc for this thread, but Jade pointed me to it > > > and I see my name came up at some

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Wed, Jun 28, 2017 at 05:45:56PM -0700, Paul E. McKenney wrote: > On Wed, Jun 28, 2017 at 05:05:46PM -0700, Linus Torvalds wrote: > > On Wed, Jun 28, 2017 at 4:54 PM, Paul E. McKenney > > wrote: > > > > > > Linus, are you dead-set against defining spin_unlock_wait()

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Wed, Jun 28, 2017 at 05:45:56PM -0700, Paul E. McKenney wrote: > On Wed, Jun 28, 2017 at 05:05:46PM -0700, Linus Torvalds wrote: > > On Wed, Jun 28, 2017 at 4:54 PM, Paul E. McKenney > > wrote: > > > > > > Linus, are you dead-set against defining spin_unlock_wait() to be > > > spin_lock +

Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.

On Thu, Jun 15, 2017 at 10:56:29AM -0700, Paul E. McKenney wrote: [...] > > > > > > FWLIW, I agree. There was a smb_mb() in RT-linux's equivalent of > > > swait_activate(). > > > > > > https://www.spinics.net/lists/linux-rt-users/msg10340.html > > > > > > If the barrier goes in swait_active()

Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.

On Thu, Jun 15, 2017 at 10:56:29AM -0700, Paul E. McKenney wrote: [...] > > > > > > FWLIW, I agree. There was a smb_mb() in RT-linux's equivalent of > > > swait_activate(). > > > > > > https://www.spinics.net/lists/linux-rt-users/msg10340.html > > > > > > If the barrier goes in swait_active()

Re: [RFC v2 1/2] swait: add idle variants which don't contribute to load average

On Thu, Jun 15, 2017 at 11:48:19AM -0700, Luis R. Rodriguez wrote: > There are cases where folks are using an interruptible swait when > using kthreads. This is rather confusing given you'd expect > interruptible waits to be -- interruptible, but kthreads are not > interruptible ! The reason for

Re: [RFC v2 1/2] swait: add idle variants which don't contribute to load average

On Thu, Jun 15, 2017 at 11:48:19AM -0700, Luis R. Rodriguez wrote: > There are cases where folks are using an interruptible swait when > using kthreads. This is rather confusing given you'd expect > interruptible waits to be -- interruptible, but kthreads are not > interruptible ! The reason for

Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.

edule(); In this case, a wakeup is missed, which could cause the rcu_gp_kthread waits for a long time. The reason of this is that we do a lockless swait_active() check in swake_up(). To fix this, we can either 1) add a smp_mb() in swake_up() before swait_active() to provide the proper order or 2) simply r

Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.

is missed, which could cause the rcu_gp_kthread waits for a long time. The reason of this is that we do a lockless swait_active() check in swake_up(). To fix this, we can either 1) add a smp_mb() in swake_up() before swait_active() to provide the proper order or 2) simply remove the swait_active() in sw

Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document

On Mon, Jun 12, 2017 at 04:49:29PM +0200, Peter Zijlstra wrote: > On Sun, Jun 11, 2017 at 09:56:32PM +0800, Boqun Feng wrote: > > > I think the term we use to refer this behavior is "fully-ordered"? > > Right, that is what we used to call it, and the term even occ

Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document

On Mon, Jun 12, 2017 at 04:49:29PM +0200, Peter Zijlstra wrote: > On Sun, Jun 11, 2017 at 09:56:32PM +0800, Boqun Feng wrote: > > > I think the term we use to refer this behavior is "fully-ordered"? > > Right, that is what we used to call it, and the term even occ

Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document

Hi Peter, On Fri, Jun 09, 2017 at 09:36:04PM +0200, Peter Zijlstra wrote: [...] > > > +Ordering: (go read memory-barriers.txt first) > > > + > > > +The rule of thumb: > > > + > > > + - non-RmW operations are unordered; > > > + > > > + - RmW operations that have no return value are unordered; > >

Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document

Hi Peter, On Fri, Jun 09, 2017 at 09:36:04PM +0200, Peter Zijlstra wrote: [...] > > > +Ordering: (go read memory-barriers.txt first) > > > + > > > +The rule of thumb: > > > + > > > + - non-RmW operations are unordered; > > > + > > > + - RmW operations that have no return value are unordered; > >

Re: [PATCH 3/3] arm64/locking: qspinlocks and qrwlocks support

On Wed, May 03, 2017 at 05:51:41PM +0300, Yury Norov wrote: > From: Jan Glauber > > Ported from x86_64 with paravirtualization support removed. > > Signed-off-by: Jan Glauber > > Note. This patch removes protection from direct inclusion of >

Re: [PATCH 3/3] arm64/locking: qspinlocks and qrwlocks support

On Wed, May 03, 2017 at 05:51:41PM +0300, Yury Norov wrote: > From: Jan Glauber > > Ported from x86_64 with paravirtualization support removed. > > Signed-off-by: Jan Glauber > > Note. This patch removes protection from direct inclusion of > arch/arm64/include/asm/spinlock_types.h. It's done

Re: [locking/ww_mutex] 857811a371 BUG: kernel hang in boot stage

6eff44724014 > Author: Boqun Feng <boqun.f...@gmail.com> > AuthorDate: Wed Mar 1 23:01:38 2017 +0800 > Commit: Ingo Molnar <mi...@kernel.org> > CommitDate: Thu Mar 2 09:00:39 2017 +0100 > > locking/ww_mutex: Adjust the lock number for stress test >

Re: [locking/ww_mutex] 857811a371 BUG: kernel hang in boot stage

6eff44724014 > Author: Boqun Feng > AuthorDate: Wed Mar 1 23:01:38 2017 +0800 > Commit: Ingo Molnar > CommitDate: Thu Mar 2 09:00:39 2017 +0100 > > locking/ww_mutex: Adjust the lock number for stress test > > Because there are only 12 bits in held_loc

Re: [locking/ww_mutex] 857811a371 INFO: task swapper/0:1 blocked for more than 120 seconds.

On Fri, Mar 10, 2017 at 11:07:46AM +0800, Boqun Feng wrote: > On Fri, Mar 10, 2017 at 10:56:49AM +0800, Fengguang Wu wrote: > > Hi Boqun, > > > > Hello Fengguang, > > > FYI here is another bisect result. I report it once again since the > > attached rep

Re: [locking/ww_mutex] 857811a371 INFO: task swapper/0:1 blocked for more than 120 seconds.

On Fri, Mar 10, 2017 at 11:07:46AM +0800, Boqun Feng wrote: > On Fri, Mar 10, 2017 at 10:56:49AM +0800, Fengguang Wu wrote: > > Hi Boqun, > > > > Hello Fengguang, > > > FYI here is another bisect result. I report it once again since the > > attached rep

Re: [locking/ww_mutex] 857811a371 INFO: task swapper/0:1 blocked for more than 120 seconds.

On Fri, Mar 10, 2017 at 10:56:49AM +0800, Fengguang Wu wrote: > Hi Boqun, > Hello Fengguang, > FYI here is another bisect result. I report it once again since the > attached reproduce-* may be more handy for debug. :) > That's very helpful! lkp is a bit difficult for me to set up ;-)

Re: [locking/ww_mutex] 857811a371 INFO: task swapper/0:1 blocked for more than 120 seconds.

On Fri, Mar 10, 2017 at 10:56:49AM +0800, Fengguang Wu wrote: > Hi Boqun, > Hello Fengguang, > FYI here is another bisect result. I report it once again since the > attached reproduce-* may be more handy for debug. :) > That's very helpful! lkp is a bit difficult for me to set up ;-)

Re: rcu: WARNING in rcu_seq_end

On Tue, Mar 07, 2017 at 06:26:03PM -0800, Paul E. McKenney wrote: > On Wed, Mar 08, 2017 at 09:39:13AM +0800, Boqun Feng wrote: > > On Tue, Mar 07, 2017 at 03:31:54PM -0800, Paul E. McKenney wrote: > > > On Wed, Mar 08, 2017 at 07:05:13AM +0800, Boqun Feng wrote: > > > &

Re: rcu: WARNING in rcu_seq_end

On Tue, Mar 07, 2017 at 06:26:03PM -0800, Paul E. McKenney wrote: > On Wed, Mar 08, 2017 at 09:39:13AM +0800, Boqun Feng wrote: > > On Tue, Mar 07, 2017 at 03:31:54PM -0800, Paul E. McKenney wrote: > > > On Wed, Mar 08, 2017 at 07:05:13AM +0800, Boqun Feng wrote: > > > &

Re: rcu: WARNING in rcu_seq_end

On Tue, Mar 07, 2017 at 03:31:54PM -0800, Paul E. McKenney wrote: > On Wed, Mar 08, 2017 at 07:05:13AM +0800, Boqun Feng wrote: > > On Tue, Mar 07, 2017 at 07:27:15AM -0800, Paul E. McKenney wrote: > > > On Tue, Mar 07, 2017 at 03:43:42PM +0100, Dmitry Vyukov wrote: > >

Re: rcu: WARNING in rcu_seq_end

On Tue, Mar 07, 2017 at 03:31:54PM -0800, Paul E. McKenney wrote: > On Wed, Mar 08, 2017 at 07:05:13AM +0800, Boqun Feng wrote: > > On Tue, Mar 07, 2017 at 07:27:15AM -0800, Paul E. McKenney wrote: > > > On Tue, Mar 07, 2017 at 03:43:42PM +0100, Dmitry Vyukov wrote: > >

Re: rcu: WARNING in rcu_seq_end

On Tue, Mar 07, 2017 at 07:27:15AM -0800, Paul E. McKenney wrote: > On Tue, Mar 07, 2017 at 03:43:42PM +0100, Dmitry Vyukov wrote: > > On Tue, Mar 7, 2017 at 3:27 PM, Boqun Feng <boqun.f...@gmail.com> wrote: > > > On Tue, Mar 07, 2017 at 08:05:19AM +0

Re: rcu: WARNING in rcu_seq_end

On Tue, Mar 07, 2017 at 07:27:15AM -0800, Paul E. McKenney wrote: > On Tue, Mar 07, 2017 at 03:43:42PM +0100, Dmitry Vyukov wrote: > > On Tue, Mar 7, 2017 at 3:27 PM, Boqun Feng wrote: > > > On Tue, Mar 07, 2017 at 08:05:19AM +0100, Dmitry Vyukov wrote: > > > [..

Re: rcu: WARNING in rcu_seq_end

On Tue, Mar 07, 2017 at 08:05:19AM +0100, Dmitry Vyukov wrote: [...] > >> > >> What is that mutex? And what locks/unlocks provide synchronization? I > >> see that one uses exp_mutex and another -- exp_wake_mutex. > > > > Both of them. > > > > ->exp_mutex is acquired by the task requesting the

Re: rcu: WARNING in rcu_seq_end

On Tue, Mar 07, 2017 at 08:05:19AM +0100, Dmitry Vyukov wrote: [...] > >> > >> What is that mutex? And what locks/unlocks provide synchronization? I > >> see that one uses exp_mutex and another -- exp_wake_mutex. > > > > Both of them. > > > > ->exp_mutex is acquired by the task requesting the

[tip:locking/urgent] locking/ww_mutex: Adjust the lock number for stress test

Commit-ID: 857811a37129f5d2ba162d7be3986eff44724014 Gitweb: http://git.kernel.org/tip/857811a37129f5d2ba162d7be3986eff44724014 Author: Boqun Feng <boqun.f...@gmail.com> AuthorDate: Wed, 1 Mar 2017 23:01:38 +0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Thu, 2 Ma

[tip:locking/urgent] locking/ww_mutex: Adjust the lock number for stress test

Commit-ID: 857811a37129f5d2ba162d7be3986eff44724014 Gitweb: http://git.kernel.org/tip/857811a37129f5d2ba162d7be3986eff44724014 Author: Boqun Feng AuthorDate: Wed, 1 Mar 2017 23:01:38 +0800 Committer: Ingo Molnar CommitDate: Thu, 2 Mar 2017 09:00:39 +0100 locking/ww_mutex: Adjust

Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff

? process_scheduled_works+0x24/0x24 > [ 17.172115] ? __kthread_create_on_node+0x11f/0x11f > [ 17.172115] ret_from_fork+0x21/0x30 > > Which is an entirely different error.. Lemme look into that. In test-ww_mutex, the stress will use 4096 locks to do the test, and given held_lock::r

Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff

? process_scheduled_works+0x24/0x24 > [ 17.172115] ? __kthread_create_on_node+0x11f/0x11f > [ 17.172115] ret_from_fork+0x21/0x30 > > Which is an entirely different error.. Lemme look into that. In test-ww_mutex, the stress will use 4096 locks to do the test, and given held_lock:

Re: [PATCH v3] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

(Really add Will this time ...) On Mon, Feb 20, 2017 at 12:53:58PM +0800, Boqun Feng wrote: > On Mon, Feb 20, 2017 at 05:20:52AM +0100, Andrea Parri wrote: > > On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote: > > > All the locking related cmpxchg's in the f

Re: [PATCH v3] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

(Really add Will this time ...) On Mon, Feb 20, 2017 at 12:53:58PM +0800, Boqun Feng wrote: > On Mon, Feb 20, 2017 at 05:20:52AM +0100, Andrea Parri wrote: > > On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote: > > > All the locking related cmpxchg's in the f

Re: [PATCH v3] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Mon, Feb 20, 2017 at 05:20:52AM +0100, Andrea Parri wrote: > On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote: > > All the locking related cmpxchg's in the following functions are > > replaced with the _acquire variants: > > - pv_queued_spin_steal_lock() > > -

Re: [PATCH v3] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Mon, Feb 20, 2017 at 05:20:52AM +0100, Andrea Parri wrote: > On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote: > > All the locking related cmpxchg's in the following functions are > > replaced with the _acquire variants: > > - pv_queued_spin_steal_lock() > > -

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Mon, Feb 13, 2017 at 10:24:38AM +0800, panxinhui wrote: > > > 在 2017/2/10 上午4:53, Waiman Long 写道: > > On 02/07/2017 10:39 PM, Xinhui Pan wrote: > >> > >> > >> 2016-12-26 4:26 GMT+08:00 Waiman Long >> >: > >> > >> A number of cmpxchg calls

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Mon, Feb 13, 2017 at 10:24:38AM +0800, panxinhui wrote: > > > 在 2017/2/10 上午4:53, Waiman Long 写道: > > On 02/07/2017 10:39 PM, Xinhui Pan wrote: > >> > >> > >> 2016-12-26 4:26 GMT+08:00 Waiman Long >> >: > >> > >> A number of cmpxchg calls in

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Wed, Feb 08, 2017 at 03:09:33PM +0800, Pan Xinhui wrote: > > > 在 2017/2/8 14:09, Boqun Feng 写道: > > On Wed, Feb 08, 2017 at 12:05:40PM +0800, Boqun Feng wrote: > > > On Wed, Feb 08, 2017 at 11:39:10AM +0800, Xinhui Pan wrote: > > > > 2016-12-26 4:26 GMT+0

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Wed, Feb 08, 2017 at 03:09:33PM +0800, Pan Xinhui wrote: > > > 在 2017/2/8 14:09, Boqun Feng 写道: > > On Wed, Feb 08, 2017 at 12:05:40PM +0800, Boqun Feng wrote: > > > On Wed, Feb 08, 2017 at 11:39:10AM +0800, Xinhui Pan wrote: > > > > 2

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Wed, Feb 08, 2017 at 12:05:40PM +0800, Boqun Feng wrote: > On Wed, Feb 08, 2017 at 11:39:10AM +0800, Xinhui Pan wrote: > > 2016-12-26 4:26 GMT+08:00 Waiman Long <long...@redhat.com>: > > > > > A number of cmpxchg calls in qspinlock_paravirt.h were replaced

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Wed, Feb 08, 2017 at 12:05:40PM +0800, Boqun Feng wrote: > On Wed, Feb 08, 2017 at 11:39:10AM +0800, Xinhui Pan wrote: > > 2016-12-26 4:26 GMT+08:00 Waiman Long : > > > > > A number of cmpxchg calls in qspinlock_paravirt.h were replaced by more > > > relaxe

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Wed, Feb 08, 2017 at 11:39:10AM +0800, Xinhui Pan wrote: > 2016-12-26 4:26 GMT+08:00 Waiman Long : > > > A number of cmpxchg calls in qspinlock_paravirt.h were replaced by more > > relaxed versions to improve performance on architectures that use LL/SC. > > > > All the

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Wed, Feb 08, 2017 at 11:39:10AM +0800, Xinhui Pan wrote: > 2016-12-26 4:26 GMT+08:00 Waiman Long : > > > A number of cmpxchg calls in qspinlock_paravirt.h were replaced by more > > relaxed versions to improve performance on architectures that use LL/SC. > > > > All the locking related

Re: [PATCH 4/5] atomic: Introduce atomic_try_cmpxchg()

On Mon, Feb 06, 2017 at 12:24:28PM +0800, Boqun Feng wrote: > On Fri, Feb 03, 2017 at 02:26:02PM +0100, Peter Zijlstra wrote: > > Add a new cmpxchg interface: > > > > bool try_cmpxchg(u{8,16,32,64} *ptr, u{8,16,32,64} *val, u{8,16,32,64} > > new); > > > &g

Re: [PATCH 4/5] atomic: Introduce atomic_try_cmpxchg()

On Mon, Feb 06, 2017 at 12:24:28PM +0800, Boqun Feng wrote: > On Fri, Feb 03, 2017 at 02:26:02PM +0100, Peter Zijlstra wrote: > > Add a new cmpxchg interface: > > > > bool try_cmpxchg(u{8,16,32,64} *ptr, u{8,16,32,64} *val, u{8,16,32,64} > > new); > > > &g

Re: [PATCH 4/5] atomic: Introduce atomic_try_cmpxchg()

On Fri, Feb 03, 2017 at 02:26:02PM +0100, Peter Zijlstra wrote: > Add a new cmpxchg interface: > > bool try_cmpxchg(u{8,16,32,64} *ptr, u{8,16,32,64} *val, u{8,16,32,64} new); > > Where the boolean returns the result of the compare; and thus if the > exchange happened; and in case of failure,

Re: [PATCH 4/5] atomic: Introduce atomic_try_cmpxchg()

On Fri, Feb 03, 2017 at 02:26:02PM +0100, Peter Zijlstra wrote: > Add a new cmpxchg interface: > > bool try_cmpxchg(u{8,16,32,64} *ptr, u{8,16,32,64} *val, u{8,16,32,64} new); > > Where the boolean returns the result of the compare; and thus if the > exchange happened; and in case of failure,

Re: [PATCH v5 01/13] lockdep: Refactor lookup_chain_cache()

On Wed, Jan 18, 2017 at 10:17:27PM +0900, Byungchul Park wrote: > Currently, lookup_chain_cache() provides both 'lookup' and 'add' > functionalities in a function. However, each is useful. So this > patch makes lookup_chain_cache() only do 'lookup' functionality and > makes add_chain_cahce() only

Re: [PATCH v5 01/13] lockdep: Refactor lookup_chain_cache()

On Wed, Jan 18, 2017 at 10:17:27PM +0900, Byungchul Park wrote: > Currently, lookup_chain_cache() provides both 'lookup' and 'add' > functionalities in a function. However, each is useful. So this > patch makes lookup_chain_cache() only do 'lookup' functionality and > makes add_chain_cahce() only

Re: [PATCH v4 15/15] lockdep: Crossrelease feature documentation

On Fri, Dec 09, 2016 at 02:12:11PM +0900, Byungchul Park wrote: [...] > +Example 1: > + > + CONTEXT XCONTEXT Y > + -- > + mutext_lock A > +lock_page B > + lock_page B > +mutext_lock A /* DEADLOCK */

Re: [PATCH v4 15/15] lockdep: Crossrelease feature documentation

On Fri, Dec 09, 2016 at 02:12:11PM +0900, Byungchul Park wrote: [...] > +Example 1: > + > + CONTEXT XCONTEXT Y > + -- > + mutext_lock A > +lock_page B > + lock_page B > +mutext_lock A /* DEADLOCK */

Re: [PATCH v4 07/15] lockdep: Implement crossrelease feature

On Tue, Jan 17, 2017 at 11:33:41AM +0900, Byungchul Park wrote: > On Mon, Jan 16, 2017 at 04:13:19PM +0100, Peter Zijlstra wrote: > > On Fri, Dec 09, 2016 at 02:12:03PM +0900, Byungchul Park wrote: > > > + /* > > > + * We assign class_idx here redundantly even though following > > > + * memcpy

Re: [PATCH v4 07/15] lockdep: Implement crossrelease feature

On Tue, Jan 17, 2017 at 11:33:41AM +0900, Byungchul Park wrote: > On Mon, Jan 16, 2017 at 04:13:19PM +0100, Peter Zijlstra wrote: > > On Fri, Dec 09, 2016 at 02:12:03PM +0900, Byungchul Park wrote: > > > + /* > > > + * We assign class_idx here redundantly even though following > > > + * memcpy

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Thu, Jan 05, 2017 at 10:17:46AM -0500, Waiman Long wrote: > On 01/05/2017 03:16 AM, Pan Xinhui wrote: > > > > > > 在 2017/1/4 17:41, Peter Zijlstra 写道: > >> On Tue, Jan 03, 2017 at 05:07:54PM -0500, Waiman Long wrote: > >>> On 01/03/2017 11:18 AM, Peter Zijlstra wrote: > On Sun, Dec 25,

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Thu, Jan 05, 2017 at 10:17:46AM -0500, Waiman Long wrote: > On 01/05/2017 03:16 AM, Pan Xinhui wrote: > > > > > > 在 2017/1/4 17:41, Peter Zijlstra 写道: > >> On Tue, Jan 03, 2017 at 05:07:54PM -0500, Waiman Long wrote: > >>> On 01/03/2017 11:18 AM, Peter Zijlstra wrote: > On Sun, Dec 25,

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Thu, Jan 05, 2017 at 04:16:38PM +0800, Pan Xinhui wrote: > > > 在 2017/1/4 17:41, Peter Zijlstra 写道: > > On Tue, Jan 03, 2017 at 05:07:54PM -0500, Waiman Long wrote: > > > On 01/03/2017 11:18 AM, Peter Zijlstra wrote: > > > > On Sun, Dec 25, 2016 at 03:26:01PM -0500, Waiman Long wrote: > > > >

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

On Thu, Jan 05, 2017 at 04:16:38PM +0800, Pan Xinhui wrote: > > > 在 2017/1/4 17:41, Peter Zijlstra 写道: > > On Tue, Jan 03, 2017 at 05:07:54PM -0500, Waiman Long wrote: > > > On 01/03/2017 11:18 AM, Peter Zijlstra wrote: > > > > On Sun, Dec 25, 2016 at 03:26:01PM -0500, Waiman Long wrote: > > > >

Re: [RFC PATCH 6/7] locking/rtqspinlock: Voluntarily yield CPU when need_sched()

On Tue, Jan 03, 2017 at 01:00:29PM -0500, Waiman Long wrote: > Ideally we want the CPU to be preemptible even when inside or waiting > for a lock. We cannot make it preemptible when inside a lock critical > section, but we can try to make the task voluntarily yield the CPU > when waiting for a

Re: [RFC PATCH 6/7] locking/rtqspinlock: Voluntarily yield CPU when need_sched()

On Tue, Jan 03, 2017 at 01:00:29PM -0500, Waiman Long wrote: > Ideally we want the CPU to be preemptible even when inside or waiting > for a lock. We cannot make it preemptible when inside a lock critical > section, but we can try to make the task voluntarily yield the CPU > when waiting for a

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

Hi Wainman, On Sun, Dec 25, 2016 at 03:26:01PM -0500, Waiman Long wrote: > A number of cmpxchg calls in qspinlock_paravirt.h were replaced by more > relaxed versions to improve performance on architectures that use LL/SC. > > All the locking related cmpxchg's are replaced with the _acquire >

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

Hi Wainman, On Sun, Dec 25, 2016 at 03:26:01PM -0500, Waiman Long wrote: > A number of cmpxchg calls in qspinlock_paravirt.h were replaced by more > relaxed versions to improve performance on architectures that use LL/SC. > > All the locking related cmpxchg's are replaced with the _acquire >

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

On Wed, Dec 21, 2016 at 08:48:45AM -0800, Paul E. McKenney wrote: > On Wed, Dec 21, 2016 at 12:18:08PM +0800, Boqun Feng wrote: > > On Tue, Dec 20, 2016 at 07:40:24PM -0800, Paul E. McKenney wrote: > > [...] > > > > > > > > Agreed, my intent is to keep this

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

On Wed, Dec 21, 2016 at 08:48:45AM -0800, Paul E. McKenney wrote: > On Wed, Dec 21, 2016 at 12:18:08PM +0800, Boqun Feng wrote: > > On Tue, Dec 20, 2016 at 07:40:24PM -0800, Paul E. McKenney wrote: > > [...] > > > > > > > > Agreed, my intent is to keep this

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

) to locate the > > > incoming CPU's rcu_data structure. This works for the boot CPU and > > > for > > > all CPUs onlined after rcu_init() executes (during very early boot). > > > Currently, this is the full set of CPUs, so all is well. But i

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

t; incoming CPU's rcu_data structure. This works for the boot CPU and > > > for > > > all CPUs onlined after rcu_init() executes (during very early boot). > > > Currently, this is the full set of CPUs, so all is well. But if > > > anyone ever par

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

On Tue, Dec 20, 2016 at 07:23:52AM -0800, Paul E. McKenney wrote: > On Tue, Dec 20, 2016 at 01:59:14PM +0800, Boqun Feng wrote: > > On Mon, Dec 19, 2016 at 09:09:13PM -0800, Paul E. McKenney wrote: > > > On Mon, Dec 19, 2016 at 11:15:15PM +0800, Boqun Feng wrote: > > > &

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

On Tue, Dec 20, 2016 at 07:23:52AM -0800, Paul E. McKenney wrote: > On Tue, Dec 20, 2016 at 01:59:14PM +0800, Boqun Feng wrote: > > On Mon, Dec 19, 2016 at 09:09:13PM -0800, Paul E. McKenney wrote: > > > On Mon, Dec 19, 2016 at 11:15:15PM +0800, Boqun Feng wrote: > > > &

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

On Tue, Dec 20, 2016 at 01:59:14PM +0800, Boqun Feng wrote: > On Mon, Dec 19, 2016 at 09:09:13PM -0800, Paul E. McKenney wrote: > > On Mon, Dec 19, 2016 at 11:15:15PM +0800, Boqun Feng wrote: > > > On Thu, Dec 15, 2016 at 02:51:36PM +, Colin Ian King wrote: > > >

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

On Tue, Dec 20, 2016 at 01:59:14PM +0800, Boqun Feng wrote: > On Mon, Dec 19, 2016 at 09:09:13PM -0800, Paul E. McKenney wrote: > > On Mon, Dec 19, 2016 at 11:15:15PM +0800, Boqun Feng wrote: > > > On Thu, Dec 15, 2016 at 02:51:36PM +, Colin Ian King wrote: > > >

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

On Mon, Dec 19, 2016 at 09:09:13PM -0800, Paul E. McKenney wrote: > On Mon, Dec 19, 2016 at 11:15:15PM +0800, Boqun Feng wrote: > > On Thu, Dec 15, 2016 at 02:51:36PM +, Colin Ian King wrote: > > > On 15/12/16 14:42, Boqun Feng wrote: > > > > On Thu, Dec 15,

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

On Mon, Dec 19, 2016 at 09:09:13PM -0800, Paul E. McKenney wrote: > On Mon, Dec 19, 2016 at 11:15:15PM +0800, Boqun Feng wrote: > > On Thu, Dec 15, 2016 at 02:51:36PM +, Colin Ian King wrote: > > > On 15/12/16 14:42, Boqun Feng wrote: > > > > On Thu, Dec 15,

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

On Thu, Dec 15, 2016 at 02:51:36PM +, Colin Ian King wrote: > On 15/12/16 14:42, Boqun Feng wrote: > > On Thu, Dec 15, 2016 at 12:04:59PM +, Mark Rutland wrote: > >> On Thu, Dec 15, 2016 at 10:42:03AM +0800, Boqun Feng wrote: > >>> ->qsmask of an RCU leaf

Re: [RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

On Thu, Dec 15, 2016 at 02:51:36PM +, Colin Ian King wrote: > On 15/12/16 14:42, Boqun Feng wrote: > > On Thu, Dec 15, 2016 at 12:04:59PM +, Mark Rutland wrote: > >> On Thu, Dec 15, 2016 at 10:42:03AM +0800, Boqun Feng wrote: > >>> ->qsmask of an RCU leaf

[RFC v2.1 1/5] rcu: Introduce for_each_leaf_node_cpu()

masks should be a subset of possible CPUs, so we don't need extra check with cpu_possible(), however, a WARN_ON_ONCE() is put to check whether there are some nasty cases we miss, and we skip that "impossible" CPU in that case. Signed-off-by: Boqun Feng <boqun.f...@gmail.com>

[RFC v2.1 1/5] rcu: Introduce for_each_leaf_node_cpu()

masks should be a subset of possible CPUs, so we don't need extra check with cpu_possible(), however, a WARN_ON_ONCE() is put to check whether there are some nasty cases we miss, and we skip that "impossible" CPU in that case. Signed-off-by: Boqun Feng --- kernel/rcu/tree.h | 19 +

Re: [RFC v2 1/5] rcu: Introduce for_each_leaf_node_cpu()

On Thu, Dec 15, 2016 at 03:10:15PM +, Mark Rutland wrote: > On Thu, Dec 15, 2016 at 10:38:58PM +0800, Boqun Feng wrote: > > On Thu, Dec 15, 2016 at 11:43:52AM +, Mark Rutland wrote: > > > On Thu, Dec 15, 2016 at 10:42:00AM +0800, Boqun Feng wrote: > > >

Re: [RFC v2 1/5] rcu: Introduce for_each_leaf_node_cpu()

On Thu, Dec 15, 2016 at 03:10:15PM +, Mark Rutland wrote: > On Thu, Dec 15, 2016 at 10:38:58PM +0800, Boqun Feng wrote: > > On Thu, Dec 15, 2016 at 11:43:52AM +, Mark Rutland wrote: > > > On Thu, Dec 15, 2016 at 10:42:00AM +0800, Boqun Feng wrote: > > >

Re: [RFC v2 1/5] rcu: Introduce for_each_leaf_node_cpu()

On Thu, Dec 15, 2016 at 11:43:52AM +, Mark Rutland wrote: > On Thu, Dec 15, 2016 at 10:42:00AM +0800, Boqun Feng wrote: > > There are some places inside RCU core, where we need to iterate all mask > > (->qsmask, ->expmask, etc) bits in a leaf node, in order to iterate

Re: [RFC v2 1/5] rcu: Introduce for_each_leaf_node_cpu()

On Thu, Dec 15, 2016 at 11:43:52AM +, Mark Rutland wrote: > On Thu, Dec 15, 2016 at 10:42:00AM +0800, Boqun Feng wrote: > > There are some places inside RCU core, where we need to iterate all mask > > (->qsmask, ->expmask, etc) bits in a leaf node, in order to iterate

<    4   5   6   7   8   9   10   11   12   13   >