Re: [RFC][PATCH 7/7] kref: Implement using refcount_t

On Fri, Nov 18, 2016 at 12:37:18PM +0100, Peter Zijlstra wrote: [snip] > + > +/* > + * Similar to atomic_inc(), will saturate at UINT_MAX and WARN. > + * > + * Provides no memory ordering, it is assumed the caller already has a > + * reference on the object, will WARN when this is not so. > + */ >

Re: [RFC][PATCH 7/7] kref: Implement using refcount_t

On Mon, Nov 21, 2016 at 10:02:23AM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 04:44:28PM +0800, Boqun Feng wrote: > > On Fri, Nov 18, 2016 at 12:37:18PM +0100, Peter Zijlstra wrote: > > [snip] > > > + > > > +/* > > > + * Similar to atomic

[RFC 2/5] rcu: Use leaf_node_for_each_mask_possible_cpu() in RCU stall checking

Replace for_each_leaf_node_possible_cpu() loop with leaf_node_for_each_mask_possible_cpu() loop to gain fewer checks in RCU stall checking code. Signed-off-by: Boqun Feng --- kernel/rcu/tree.c | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/kernel

[RFC 1/5] rcu: Introduce primitives to iterate mask bits in an RCU leaf node

sk bits in a more efficient way. Signed-off-by: Boqun Feng --- kernel/rcu/tree.h | 30 ++ 1 file changed, 30 insertions(+) diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h index c0a4bf8f1ed0..4078a8ec2bd1 100644 --- a/kernel/rcu/tree.h +++ b/kernel/rcu/tree.h

[RFC 0/5] rcu: Introduce leaf_node_for_each_mask_possible_cpu() and its friend

Hi Paul, While reading the discussion at: https://marc.info/?l=linux-kernel&m=148044253400769 I figured we might use this fact to save some extra checks in RCU core code, currently we iterate over all the possible CPUs on a leaf node, check whether they were masked in a certain mask and do somet

[RFC 4/5] rcu: Use leaf_node_for_each_mask_possible_cpu() in force_qs_rnp()

->qsmask of an RCU leaf node is usually more sparse than the corresponding cpu_possible_mask. So replace the for_each_leaf_node_possible_cpu() in force_qs_rnp() with leaf_node_for_each_mask_possible_cpu() to save several checks. Signed-off-by: Boqun Feng --- kernel/rcu/tree.c |

[RFC 5/5] rcu: Use leaf_node_for_each_mask_*() for leaf node online CPU iteration

-by: Boqun Feng --- kernel/rcu/tree_plugin.h | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 69c6eb27c37f..c954c2a7a9ba 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -1170,15 +1170,17 @@ sta

[RFC 3/5] rcu: Use leaf_node_for_each_mask_possible_cpu() for ->expmask iteration

The ->expmask of an RCU leaf node should be more sparse than the corresponding part of cpu_possible_mask, iterating on ->expmask bitmap rather cpu_possible_mask to save some checks. Signed-off-by: Boqun Feng --- kernel/rcu/tree_exp.h | 17 + 1 file changed, 5 insertions(

Re: [RFC 0/5] rcu: Introduce leaf_node_for_each_mask_possible_cpu() and its friend

On Fri, Dec 09, 2016 at 03:49:45PM -0800, Paul E. McKenney wrote: > On Fri, Dec 09, 2016 at 04:48:22PM +0800, Boqun Feng wrote: > > Hi Paul, > > > > While reading the discussion at: > > > > https://marc.info/?l=linux-kernel&m=148044253400769 > >

Re: [RFC 0/5] rcu: Introduce leaf_node_for_each_mask_possible_cpu() and its friend

On Fri, Dec 09, 2016 at 08:28:05PM -0800, Paul E. McKenney wrote: > On Sat, Dec 10, 2016 at 08:45:38AM +0800, Boqun Feng wrote: > > On Fri, Dec 09, 2016 at 03:49:45PM -0800, Paul E. McKenney wrote: > > > On Fri, Dec 09, 2016 at 04:48:22PM +0800, Boqun Feng wrot

Re: [RFC 0/5] rcu: Introduce leaf_node_for_each_mask_possible_cpu() and its friend

On Sat, Dec 10, 2016 at 09:38:54AM -0800, Paul E. McKenney wrote: > On Sat, Dec 10, 2016 at 09:36:29PM +0800, Boqun Feng wrote: > > On Fri, Dec 09, 2016 at 08:28:05PM -0800, Paul E. McKenney wrote: > > > On Sat, Dec 10, 2016 at 08:45:38AM +0800, Boqun Feng 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 grace

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 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: > > &g

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: [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 ;-) Regards,

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: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier

On Thu, Jun 16, 2016 at 05:35:54PM -0400, Waiman Long wrote: > On 06/15/2016 10:19 PM, Boqun Feng wrote: > > On Wed, Jun 15, 2016 at 03:01:19PM -0400, Waiman Long wrote: > > > On 06/15/2016 04:04 AM, Boqun Feng wrote: > > > > Hi Waiman, > > > > > &

Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier

On Fri, Jun 17, 2016 at 02:17:27PM -0400, Waiman Long wrote: > On 06/17/2016 11:45 AM, Will Deacon wrote: > > On Fri, Jun 17, 2016 at 11:26:41AM -0400, Waiman Long wrote: > > > On 06/16/2016 08:48 PM, Boqun Feng wrote: > > > > On Thu, Jun 16, 2016 at 05:35

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

d/0xf2 > [ 17.172115] ? 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 th

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 qspinlock_paravirt.h

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() > > - trylock_clear_pending(

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

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, t

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 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 cmpxchg's

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 > > > relaxed v

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: [RFC PATCH v7 1/7] Restartable sequences system call

On Wed, Aug 03, 2016 at 10:03:32PM -0700, Andy Lutomirski wrote: > On Wed, Aug 3, 2016 at 9:27 PM, Boqun Feng wrote: > > On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote: > >> On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra > >> wrote: > >>

Re: [RFC PATCH v7 1/7] Restartable sequences system call

On Wed, Aug 10, 2016 at 05:33:44PM +, Mathieu Desnoyers wrote: > - On Aug 9, 2016, at 12:13 PM, Boqun Feng boqun.f...@gmail.com wrote: > > > > > > > However, I'm thinking maybe we can use some tricks to avoid unnecessary > > aborts-on-preemption.

Re: [RFC PATCH v7 1/7] Restartable sequences system call

On Wed, Aug 03, 2016 at 03:19:40PM +0200, Peter Zijlstra wrote: > On Thu, Jul 21, 2016 at 05:14:16PM -0400, Mathieu Desnoyers wrote: > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 1209323..daef027 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5085,6 +5085,13 @@ M: Joe Perches

Re: [RFC PATCH v7 1/7] Restartable sequences system call

On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote: > On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra wrote: > > On Tue, Jul 26, 2016 at 03:02:19AM +, Mathieu Desnoyers wrote: > >> We really care about preemption here. Every migration implies a > >> preemption from a user-space per

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Mon, Aug 29, 2016 at 03:16:52PM +, Mathieu Desnoyers wrote: > - On Aug 27, 2016, at 12:22 AM, Josh Triplett j...@joshtriplett.org wrote: > > > On Thu, Aug 25, 2016 at 05:56:25PM +, Ben Maurer wrote: > >> rseq opens up a whole world of algorithms to userspace – algorithms > >> that a

Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait()

On Mon, Jun 06, 2016 at 06:08:36PM +0200, Peter Zijlstra wrote: > On Thu, Jun 02, 2016 at 06:57:00PM +0100, Will Deacon wrote: > > > This 'replaces' commit: > > > > > > 54cf809b9512 ("locking,qspinlock: Fix spin_is_locked() and > > > spin_unlock_wait()") > > > > > > and seems to still work wit

Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait()

On Tue, Jun 07, 2016 at 02:00:16PM +0200, Peter Zijlstra wrote: > On Tue, Jun 07, 2016 at 07:43:15PM +0800, Boqun Feng wrote: > > On Mon, Jun 06, 2016 at 06:08:36PM +0200, Peter Zijlstra wrote: > > > diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c > &

Re: [RFC PATCH v2 6/7] lib/persubnode: Introducing a simple per-subnode APIs

On Mon, Jul 11, 2016 at 01:32:11PM -0400, Waiman Long wrote: > The percpu APIs are extensively used in the Linux kernel to reduce > cacheline contention and improve performance. For some use cases, the > percpu APIs may be too fine-grain for distributed resources whereas > a per-node based allocati

Re: [PATCH] locking/qspinlock: Use atomic_sub_return_release in queued_spin_unlock

On Mon, Jun 13, 2016 at 12:45:23PM -0700, Davidlohr Bueso wrote: > On Fri, 03 Jun 2016, Pan Xinhui wrote: > > > The existing version uses a heavy barrier while only release semantics > > is required. So use atomic_sub_return_release instead. > > > > Suggested-by: Peter Zijlstra (Intel) > > Signe

Re: [v2] powerpc: spinlock: Fix spin_unlock_wait()

On Mon, Jun 06, 2016 at 02:52:05PM +1000, Michael Ellerman wrote: > On Fri, 2016-03-06 at 03:49:48 UTC, Boqun Feng wrote: > > There is an ordering issue with spin_unlock_wait() on powerpc, because > > the spin_lock primitive is an ACQUIRE and an ACQUIRE is only ordering > >

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Sat, Jun 25, 2016 at 04:24:47PM +0200, Peter Zijlstra wrote: > On Sat, Jun 25, 2016 at 01:42:03PM -0400, Pan Xinhui wrote: > > An over-committed guest with more vCPUs than pCPUs has a heavy overload > > in osq_lock(). > > > > This is because vCPU A hold the osq lock and yield out, vCPU B wait >

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Sat, Jun 25, 2016 at 06:09:22PM +0200, Peter Zijlstra wrote: > On Sat, Jun 25, 2016 at 11:21:30PM +0800, Boqun Feng wrote: > > > > > > int vpc = vcpu_preempt_count(); > > > > > > ... > > > > > > for (;;) { > > >

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Sat, Jun 25, 2016 at 06:15:40PM +0200, Peter Zijlstra wrote: > On Sat, Jun 25, 2016 at 11:21:30PM +0800, Boqun Feng wrote: > > So on PPC, we have lppaca::yield_count to detect when an vcpu is > > preempted, if the yield_count is even, the vcpu is running, otherwise it &

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Sat, Jun 25, 2016 at 09:20:25PM +0200, Peter Zijlstra wrote: > On Sun, Jun 26, 2016 at 01:27:56AM +0800, panxinhui wrote: > > >> Would that not have issues where the owner cpu is kept running but the > > >> spinner (ie. _this_ vcpu) gets preempted? I would think that in that > > >> case we too w

Re: [PATCH] locking/osq: Drop the overload of osq lock

ct layer between locking functions and arch or hypervisor related code. There are two sets of primitives: 1. vcpu_preempt_count() and vcpu_has_preempted(), they must be used pairwisely in a same preempt disable critical section. And they could detect whether a vcpu preemption happens betwe

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Sun, Jun 26, 2016 at 02:10:57PM +0800, Boqun Feng wrote: > On Sun, Jun 26, 2016 at 01:21:04PM +0800, panxinhui wrote: > > > > > 在 2016年6月26日，03:20，Peter Zijlstra 写道： > > > > > > On Sun, Jun 26, 2016 at 01:27:56AM +0800, panxinhui wrote: > > >>&

Re: [PATCH] locking/osq: Drop the overload of osq lock

. And they > > could detect whether a vcpu preemption happens between them. > > > > 2. vcpu_is_preempted(), used to check whether other cpu's vcpu is > > preempted. > > > > This patch also implements those primitives on pseries and wire them up. > &g

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Sun, Jun 26, 2016 at 03:08:20PM +0800, panxinhui wrote: [snip] > > @@ -106,6 +109,9 @@ bool osq_lock(struct optimistic_spin_queue *lock) > > node->prev = prev; > > WRITE_ONCE(prev->next, node); > > > > + old = old - 1; > > + vpc = vcpu_preempt_count(); > > + > > /* > > * No

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Sun, Jun 26, 2016 at 02:59:26PM +0800, Boqun Feng wrote: [snip] > > This should be: > > extern struct vcpu_preempt_ops vcpu_preempt_ops; > > And I tested this one along with modified version of Xinhui's patch. > > The test showed that even in a not over-commit

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Mon, Jun 27, 2016 at 10:09:59AM +0200, Peter Zijlstra wrote: [snip] > > No, this is entirely insane, also broken. > > No vectors, no actual function calls, nothing like that. You want the > below to completely compile away and generate the exact 100% same code > it does today. > Point taken.

Re: [PATCH 1/3] kernel/sched: introduce vcpu preempted check interface

On Mon, Jun 27, 2016 at 01:41:28PM -0400, Pan Xinhui wrote: > this supports to fix lock holder preempted issue which run as a guest > > for kernel users, we could use bool vcpu_is_preempted(int cpu) to detech > if one vcpu is preempted or not. > > The default implementation is a macrodefined by f

Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

and dedicated mode. > So add lppaca_dedicated_proc macro in lppaca.h > > Suggested-by: Boqun Feng > Signed-off-by: Pan Xinhui > --- > arch/powerpc/include/asm/lppaca.h | 6 ++ > arch/powerpc/include/asm/spinlock.h | 15 +++ > 2 files changed, 21 insertions

Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

On Tue, Jun 28, 2016 at 11:39:18AM +0800, xinhui wrote: [snip] > > > +{ > > > + struct lppaca *lp = &lppaca_of(cpu); > > > + > > > + if (unlikely(!(lppaca_shared_proc(lp) || > > > + lppaca_dedicated_proc(lp > > > > Do you want to detect whether we are running in a guest(ie. pse

Re: [Linux-v4.6-rc1] ext4: WARNING: CPU: 2 PID: 2692 at kernel/locking/lockdep.c:2017 __lock_acquire+0x180e/0x2260

On Sun, Mar 27, 2016 at 05:03:44AM -0700, Linus Torvalds wrote: > On Sun, Mar 27, 2016 at 1:57 AM, Sedat Dilek wrote: > > > > I pulled ext4.git#dev on top of Linux v4.6-rc1... > > > > ... and did not see the call-trace. > > Unless you're using overlayfs or per-file encryption, I'm not seeing > th

Re: [Linux-v4.6-rc1] ext4: WARNING: CPU: 2 PID: 2692 at kernel/locking/lockdep.c:2017 __lock_acquire+0x180e/0x2260

On Sun, Mar 27, 2016 at 10:59:00PM +0200, Sedat Dilek wrote: > On Sun, Mar 27, 2016 at 10:48 PM, Peter Zijlstra wrote: > > On Sun, Mar 27, 2016 at 05:03:44AM -0700, Linus Torvalds wrote: > >> Anyway, I don't think that DEBUG_LOCKS_WARN_ON() in > >> > >> kernel/locking/lockdep.c:2017 __lock_acqui

[PATCH] rcu: Remove superfluous versions of rcu_read_lock_sched_held()

ng as expected and save several lines of code. Signed-off-by: Boqun Feng --- include/linux/rcupdate.h | 17 + kernel/rcu/update.c | 4 ++-- 2 files changed, 3 insertions(+), 18 deletions(-) diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index b5d48bd..e3

Re: [PATCH] rcu: Remove superfluous versions of rcu_read_lock_sched_held()

On Wed, Mar 23, 2016 at 09:38:46AM -0700, Paul E. McKenney wrote: > On Wed, Mar 23, 2016 at 11:11:48PM +0800, Boqun Feng wrote: > > Currently, we have four versions of rcu_read_lock_sched_held(), > > depending on the combined choices on PREEMPT_COUNT and DEBUG_LOCK_ALLOC. > >

Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical sections

On Mon, Feb 29, 2016 at 01:43:18PM +0100, Peter Zijlstra wrote: > On Mon, Feb 29, 2016 at 09:12:20AM +0800, Boqun Feng wrote: > > > The problem is: > > > > Currently there is no way to know which rcu_dereference() and its > > friends a rcu_read_lock() or one of

Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical sections

On Tue, Mar 01, 2016 at 11:01:34AM +0100, Peter Zijlstra wrote: > On Tue, Mar 01, 2016 at 10:57:07AM +0100, Peter Zijlstra wrote: > > On Tue, Mar 01, 2016 at 05:32:42PM +0800, Boqun Feng wrote: > > > > One could for example allow something like: > > > &g

Re: [RFC v2 3/7] powerpc: atomic: Implement atomic{,64}_{add,sub}_return_* variants

On Fri, Sep 25, 2015 at 02:29:04PM -0700, Paul E. McKenney wrote: > On Wed, Sep 23, 2015 at 08:07:55AM +0800, Boqun Feng wrote: > > On Tue, Sep 22, 2015 at 08:25:40AM -0700, Paul E. McKenney wrote: > > > On Tue, Sep 22, 2015 at 07:37:04AM +0800, Boqun Feng wrote: > > > &

Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation

On Wed, Sep 16, 2015 at 05:38:14PM +0100, Will Deacon wrote: > On Wed, Sep 16, 2015 at 12:49:18PM +0100, Boqun Feng wrote: > > Hi Will, > > Hello, > > > On Tue, Sep 15, 2015 at 05:13:30PM +0100, Will Deacon wrote: > > > +If necessary, orde

Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation

On Wed, Sep 16, 2015 at 12:07:06PM +0100, Will Deacon wrote: > On Wed, Sep 16, 2015 at 11:43:14AM +0100, Peter Zijlstra wrote: > > On Wed, Sep 16, 2015 at 11:29:08AM +0100, Will Deacon wrote: > > > > Indeed, that is a hole in the definition, that I think we should close. > > > > > I'm struggling t

Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation

On Thu, Sep 17, 2015 at 10:50:12AM +0800, Boqun Feng wrote: > On Wed, Sep 16, 2015 at 12:07:06PM +0100, Will Deacon wrote: > > On Wed, Sep 16, 2015 at 11:43:14AM +0100, Peter Zijlstra wrote: > > > On Wed, Sep 16, 2015 at 11:29:08AM +0100, Will Deacon wrote: > > > > &

Re: [PATCH] powerpc: Kconfig: remove BE-only platforms from LE kernel build

Ping ;-) Regards, Boqun On Mon, Sep 07, 2015 at 07:58:00AM +0800, Boqun Feng wrote: > Currently, little endian is only supported on powernv and pseries, > however, Kconfigs still allow us to include other platforms in a LE > kernel, this may result in space wasting or even build erro

Re: [PATCH] powerpc: Kconfig: remove BE-only platforms from LE kernel build

On Fri, Sep 18, 2015 at 07:49:56PM +1000, Michael Ellerman wrote: > On Fri, 2015-09-18 at 08:22 +0800, Boqun Feng wrote: > > Ping ;-) > > Hi Boqun, > Hello, > We keep track of patches in patchwork: > > http://patchwork.ozlabs.org/project/linuxppc-dev/list/?submi

Re: [RFC v2 3/7] powerpc: atomic: Implement atomic{,64}_{add,sub}_return_* variants

Hi Will, On Fri, Sep 18, 2015 at 05:59:02PM +0100, Will Deacon wrote: > On Wed, Sep 16, 2015 at 04:49:31PM +0100, Boqun Feng wrote: > > On powerpc, we don't need a general memory barrier to achieve acquire and > > release semantics, so __atomic_op_{acquire,release} can be i

Re: [RFC v2 3/7] powerpc: atomic: Implement atomic{,64}_{add,sub}_return_* variants

On Sat, Sep 19, 2015 at 11:33:10PM +0800, Boqun Feng wrote: > Hi Will, > > On Fri, Sep 18, 2015 at 05:59:02PM +0100, Will Deacon wrote: > > On Wed, Sep 16, 2015 at 04:49:31PM +0100, Boqun Feng wrote: > > > On powerpc, we don't need a general memory barrier to achi

Re: [RFC v2 3/7] powerpc: atomic: Implement atomic{,64}_{add,sub}_return_* variants

On Tue, Sep 22, 2015 at 08:25:40AM -0700, Paul E. McKenney wrote: > On Tue, Sep 22, 2015 at 07:37:04AM +0800, Boqun Feng wrote: > > On Tue, Sep 22, 2015 at 07:26:56AM +0800, Boqun Feng wrote: > > > On Mon, Sep 21, 2015 at 11:24:27PM +0100, Will Deacon wrote: > > > >

Re: [PATCH] Documentation: Remove misleading examples of the barriers in wake_*()

Hi Peter, On Thu, Sep 17, 2015 at 03:01:26PM +0200, Peter Zijlstra wrote: > On Thu, Sep 10, 2015 at 07:55:57PM +0200, Oleg Nesterov wrote: > > On 09/10, Boqun Feng wrote: > > > > > > On Wed, Sep 09, 2015 at 12:28:22PM -0700, Paul E. McKenney wrote: > > > &g

Re: [Question] lockdep: Is nested lock handled correctly?

Hi Peter, On Mon, Aug 10, 2015 at 01:42:28PM +0200, Peter Zijlstra wrote: > On Mon, Aug 10, 2015 at 05:52:47PM +0800, Boqun Feng wrote: > > Hi Peter and Ingo, > > > > I'm now learning the code of lockdep and find that nested lock may not > > be handled correctly b

Re: [Question] lockdep: Is nested lock handled correctly?

Hi Peter, On Mon, Aug 10, 2015 at 04:24:17PM +0200, Peter Zijlstra wrote: > On Mon, Aug 10, 2015 at 09:49:24PM +0800, Boqun Feng wrote: > > Though I don't want to have a locking order like that either, we can't > > stop others from using that order(maybe a goo

Re: [PATCH] sched/fair: code clean up for __sched_period()

Ping. Any idea on this one? On Thu, Jul 02, 2015 at 10:25:52PM +0800, Boqun Feng wrote: > Since commit: 4bf0b77158 ("sched: remove do_div() from > __sched_slice()"), the logic of __sched_period() can be implemented as a > single if-else without any local variable, so this

Re: [PATCH] sched/fair: code clean up for __sched_period()

Hi Peter, On Mon, Jul 06, 2015 at 02:49:59PM +0200, Peter Zijlstra wrote: > On Mon, Jul 06, 2015 at 08:41:26PM +0800, Boqun Feng wrote: > > Ping. Any idea on this one? > > I think I queued this one. Sorry, I only had looked up in the "tip" tree.. just found it on your t

Re: [PATCH] sched/fair: code clean up for __sched_period()

Hi Ingo, On Mon, Jul 06, 2015 at 02:53:50PM +0200, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > > > On Mon, Jul 06, 2015 at 08:41:26PM +0800, Boqun Feng wrote: > > > Ping. Any idea on this one? > > > > I think I queued this one. > > Yeah, and

Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation

On Thu, Sep 17, 2015 at 07:00:01PM +0100, Will Deacon wrote: > On Thu, Sep 17, 2015 at 03:50:12AM +0100, Boqun Feng wrote: > > On Wed, Sep 16, 2015 at 12:07:06PM +0100, Will Deacon wrote: > > > On Wed, Sep 16, 2015 at 11:43:14AM +0100, Peter Zijlstra wrote: > > > >

Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation

On Mon, Sep 21, 2015 at 09:45:15PM +0800, Boqun Feng wrote: > On Thu, Sep 17, 2015 at 07:00:01PM +0100, Will Deacon wrote: > > On Thu, Sep 17, 2015 at 03:50:12AM +0100, Boqun Feng wrote: > > > On Wed, Sep 16, 2015 at 12:07:06PM +0100, Will Deacon wrote: > > > > On W

Re: [RFC v2 3/7] powerpc: atomic: Implement atomic{,64}_{add,sub}_return_* variants

On Mon, Sep 21, 2015 at 11:24:27PM +0100, Will Deacon wrote: > Hi Boqun, > > On Sun, Sep 20, 2015 at 09:23:03AM +0100, Boqun Feng wrote: > > On Sat, Sep 19, 2015 at 11:33:10PM +0800, Boqun Feng wrote: > > > On Fri, Sep 18, 2015 at 05:59:02PM +0100, Will Deacon wrote: >

Re: [RFC v2 3/7] powerpc: atomic: Implement atomic{,64}_{add,sub}_return_* variants

On Tue, Sep 22, 2015 at 07:26:56AM +0800, Boqun Feng wrote: > On Mon, Sep 21, 2015 at 11:24:27PM +0100, Will Deacon wrote: > > Hi Boqun, > > > > On Sun, Sep 20, 2015 at 09:23:03AM +0100, Boqun Feng wrote: > > > On Sat, Sep 19, 2015 at 11:33:10PM +0800, Boqun Feng

Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation

On Mon, Sep 21, 2015 at 11:23:01PM +0100, Will Deacon wrote: > On Mon, Sep 21, 2015 at 03:10:38PM +0100, Boqun Feng wrote: > > On Mon, Sep 21, 2015 at 09:45:15PM +0800, Boqun Feng wrote: > > > On Thu, Sep 17, 2015 at 07:00:01PM +0100, Will Deacon wrote: > > > > On T

Re: [PATCH -tip 2/3] sched/wake_q: Relax to acquire semantics

Hi Martin, On Tue, Sep 22, 2015 at 12:27:35PM +0200, Martin Schwidefsky wrote: > On Mon, 21 Sep 2015 11:22:52 +0200 > Martin Schwidefsky wrote: > > > On Fri, 18 Sep 2015 14:41:20 -0700 > > "Paul E. McKenney" wrote: > > > > > On Tue, Sep 15, 2015 at 10:09:41AM -0700, Paul E. McKenney wrote: > >

Re: [PATCH -tip 2/3] sched/wake_q: Relax to acquire semantics

On Tue, Sep 22, 2015 at 02:51:36PM +0200, Martin Schwidefsky wrote: > On Tue, 22 Sep 2015 20:23:26 +0800 > Boqun Feng wrote: > > > Hi Martin, > > > > On Tue, Sep 22, 2015 at 12:27:35PM +0200, Martin Schwidefsky wrote: > > > On Mon, 21 Sep 2015 11:22:52 +

Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants

On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote: > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > > > Hi all, > > > > This is v6 of the series. > > > > Link for v1: https://lkml.org/lkml/2015/8/27/798 > > Link for v2: https://l

Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants

On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote: > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > > > Hi all, > > > > This is v6 of the series. > > > > Link for v1: https://lkml.org/lkml/2015/8/27/798 > > Link for v2: https://l

Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants

On Sun, Dec 27, 2015 at 06:53:39PM +1100, Michael Ellerman wrote: > On Wed, 2015-12-23 at 18:54 +0800, Boqun Feng wrote: > > On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote: > > > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > > > > Hi all,

[RFC v2 0/3] sparse: Introduce __private to privatize members of structs

Hi all, This is v2 of __private. Link for v1: http://marc.info/?l=linux-sparse&m=144988906932520&w=2 Change since v1: * #undef __irqd_to_state after used (Peter Zijlstra) This patchset introduces a __private modifier for sparse to detect misuses of private members of structs. This could

[RFC v2 1/3] sparse: Add __private to privatize members of structs

w_spinlock [usertype] *lock | kernel/rcu/tree.c:4453:25:got struct raw_spinlock [noderef] * Also, this patch improves compiler.h a little bit by adding comments for "#else" and "#endif". Signed-off-by: Boqun Feng --- include/linux/compiler.h | 12 scripts/chec

[RFC v2 2/3] RCU: Privatize rcu_node::lock

replaced with those wrappers. Signed-off-by: Boqun Feng --- kernel/rcu/tree.c| 103 --- kernel/rcu/tree.h| 42 ++- kernel/rcu/tree_plugin.h | 26 ++-- 3 files changed, 96 insertions(+), 75 deletions(-) diff --git a

[RFC v2 3/3] irq: Privatize irq_common_data::state_use_accessors

irq_common_data::state_use_accessors is not designed for public use. Therefore make it private so that people who write code accessing it directly will get blamed by sparse. Also #undef the macro __irqd_to_state after used in header files, so that the macro can't be misused. Signed-off-by:

Re: [RFC][PATCH] mips: Fix arch_spin_unlock()

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,

Re: [RFC][PATCH] mips: Fix arch_spin_unlock()

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

Re: [RFC][PATCH] mips: Fix arch_spin_unlock()

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

Re: [RFC][PATCH] mips: Fix arch_spin_unlock()

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

[RFC 0/3] sparse: Introduce __private to privatize members of structs

Hi all, As I proposed: http://marc.info/?l=linux-arm-kernel&m=144944469805753 , we can define a __private modifier for sparse to detect misuses of private members of structs. This could make maintenace a little easier and prevent some potential bugs. This patchset serves as a POC and consists o

[RFC 2/3] RCU: Privatize rcu_node::lock

replaced with those wrappers. Signed-off-by: Boqun Feng --- kernel/rcu/tree.c| 103 --- kernel/rcu/tree.h| 42 ++- kernel/rcu/tree_plugin.h | 26 ++-- 3 files changed, 96 insertions(+), 75 deletions(-) diff --git a

[RFC 3/3] irq: Privatize irq_common_data::state_use_accessors

According to Peter Zijlstra, irq_common_data::state_use_accessors is not designed for public use. Therefore make it private so that people who write code accessing it directly will get blamed by sparse. Signed-off-by: Boqun Feng --- include/linux/irq.h | 4 ++-- 1 file changed, 2 insertions

[RFC 1/3] sparse: Add __private to privatize members of structs

w_spinlock [usertype] *lock | kernel/rcu/tree.c:4453:25:got struct raw_spinlock [noderef] * Also, this patch improves compiler.h a little bit by adding comments for "#else" and "#endif". Signed-off-by: Boqun Feng --- include/linux/compiler.h | 12 scripts/chec

Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants

On Fri, Dec 18, 2015 at 09:12:50AM -0800, Davidlohr Bueso wrote: > I've left this series testing overnight on a power7 box and so far so good, > nothing has broken. Davidlohr, thank you for your testing! Regards, Boqun signature.asc Description: PGP signature

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 foo x = READ_ONCE(*ptr); > > >

Re: [RFC][PATCH] mips: Fix arch_spin_unlock()

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

Re: [PATCH v3] barriers: introduce smp_mb__release_acquire and update documentation

ory barrier, implying global transitivity. This could give the readers an overview of the usage of this barrier. > Cc: Boqun Feng > Cc: Paul E. McKenney > Cc: Peter Zijlstra > Signed-off-by: Will Deacon > --- > > Based on Paul's patch to describe local vs global

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 Overlapping

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 > > > smp_read_barrier_depends(), but SYNC_RMB prob

<    1   2   3   4   5   6   7   8   9   10   >