On Sat, Jun 18, 2016 at 04:46:20PM +0800, Boqun Feng wrote:
> On Fri, Jun 17, 2016 at 02:17:27PM -0400, Waiman Long wrote:
> > keep the xchg() function as it is or use smp_store_release(&next->locked,
> > 1). So which one is a better alternative for ARM or PPC?
> >
>
> For PPC, I think xchg_relea
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:54PM -0400, Waiman Long wrote:
> > > > > I
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:54PM -0400, Waiman Long wrote:
If you look into the actual code:
next = xchg_release(&node->next, NULL);
On Fri, 17 Jun 2016, Davidlohr Bueso wrote:
On Fri, 17 Jun 2016, Waiman Long wrote:
On 06/16/2016 09:11 PM, Davidlohr Bueso wrote:
On Wed, 15 Jun 2016, Peter Zijlstra wrote:
Yeah, see a few patches further in this series, where he guards a
variables with the osq_lock.
So one problem I hav
On Fri, 17 Jun 2016, Waiman Long wrote:
On 06/16/2016 09:11 PM, Davidlohr Bueso wrote:
On Wed, 15 Jun 2016, Peter Zijlstra wrote:
Yeah, see a few patches further in this series, where he guards a
variables with the osq_lock.
So one problem I have with all this is that if we are hardening
o
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:54PM -0400, Waiman Long wrote:
> >>If you look into the actual code:
> >>
> >> next = xchg_release(&node->next, NULL);
> >> if (next) {
> >>
On 06/16/2016 08:48 PM, Boqun Feng wrote:
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,
On Tue, Jun 14, 2016 at 06:48:04P
On 06/16/2016 09:11 PM, Davidlohr Bueso wrote:
On Wed, 15 Jun 2016, Peter Zijlstra wrote:
Yeah, see a few patches further in this series, where he guards a
variables with the osq_lock.
So one problem I have with all this is that if we are hardening
osq_lock/unlock()
because of some future us
On Wed, 15 Jun 2016, Peter Zijlstra wrote:
Yeah, see a few patches further in this series, where he guards a
variables with the osq_lock.
So one problem I have with all this is that if we are hardening
osq_lock/unlock()
because of some future use that is specific to rwsems, then we will immed
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,
> > > >
> > > > On Tue, Jun 14, 2016 at 06:48:04PM -0400, Wai
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,
On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote:
The osq_lock() and osq_unlock() function may not provide the necessary
acqui
Hi guys,
On Thu, Jun 16, 2016 at 10:19:51AM +0800, 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:
> > > On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote:
> > > > @@ -198,7 +198,7 @@ void osq_unlock(struct op
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,
> >
> > On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote:
> > > The osq_lock() and osq_unlock() function may not provide the necessary
> > > acquire and release barrie
On Wed, Jun 15, 2016 at 04:04:07PM -0400, Waiman Long wrote:
>
> BTW, when will the smp_acquire__after_ctrl_dep() patch goes into the tip
> tree? My patch will have a dependency on that when I make the change.
Should already be in as part of that spin_unlock_wait() fixup.
/me checks..
tip/locki
On 06/15/2016 03:08 PM, Waiman Long wrote:
On 06/15/2016 01:12 PM, Peter Zijlstra wrote:
On Wed, Jun 15, 2016 at 09:56:59AM -0700, Davidlohr Bueso wrote:
On Tue, 14 Jun 2016, Waiman Long wrote:
+++ b/kernel/locking/osq_lock.c
@@ -115,7 +115,7 @@ bool osq_lock(struct optimistic_spin_queue *lock
On 06/15/2016 01:12 PM, Peter Zijlstra wrote:
On Wed, Jun 15, 2016 at 09:56:59AM -0700, Davidlohr Bueso wrote:
On Tue, 14 Jun 2016, Waiman Long wrote:
+++ b/kernel/locking/osq_lock.c
@@ -115,7 +115,7 @@ bool osq_lock(struct optimistic_spin_queue *lock)
* cmpxchg in an attempt to undo o
On 06/15/2016 04:04 AM, Boqun Feng wrote:
Hi Waiman,
On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote:
The osq_lock() and osq_unlock() function may not provide the necessary
acquire and release barrier in some cases. This patch makes sure
that the proper barriers are provided when os
On Wed, 15 Jun 2016, Peter Zijlstra wrote:
On Wed, Jun 15, 2016 at 11:27:24AM -0700, Davidlohr Bueso wrote:
On Wed, 15 Jun 2016, Peter Zijlstra wrote:
>In any case, its fairly simple to cure, just add
>smp_acquire__after_ctrl_dep() at the end. If we bail because
>need_resched() we don't need t
On Wed, Jun 15, 2016 at 11:27:24AM -0700, Davidlohr Bueso wrote:
> On Wed, 15 Jun 2016, Peter Zijlstra wrote:
>
> >In any case, its fairly simple to cure, just add
> >smp_acquire__after_ctrl_dep() at the end. If we bail because
> >need_resched() we don't need the acquire I think.
>
> I was just c
On Wed, 15 Jun 2016, Peter Zijlstra wrote:
In any case, its fairly simple to cure, just add
smp_acquire__after_ctrl_dep() at the end. If we bail because
need_resched() we don't need the acquire I think.
I was just considering this for your smp_cond_acquire/smp_cond_load_acquire
rework, so yeah
On Wed, Jun 15, 2016 at 04:04:46PM +0800, Boqun Feng wrote:
> On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote:
> > @@ -198,7 +198,7 @@ void osq_unlock(struct optimistic_spin_queue *lock)
> > * Second most likely case.
> > */
> > node = this_cpu_ptr(&osq_node);
> > - nex
On Wed, Jun 15, 2016 at 09:56:59AM -0700, Davidlohr Bueso wrote:
> On Tue, 14 Jun 2016, Waiman Long wrote:
> >+++ b/kernel/locking/osq_lock.c
> >@@ -115,7 +115,7 @@ bool osq_lock(struct optimistic_spin_queue *lock)
> > * cmpxchg in an attempt to undo our queueing.
> > */
> >
> >-whil
On Tue, 14 Jun 2016, Waiman Long wrote:
The osq_lock() and osq_unlock() function may not provide the necessary
acquire and release barrier in some cases. This patch makes sure
that the proper barriers are provided when osq_lock() is successful
or when osq_unlock() is called.
Signed-off-by: Waim
Hi Waiman,
On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote:
> The osq_lock() and osq_unlock() function may not provide the necessary
> acquire and release barrier in some cases. This patch makes sure
> that the proper barriers are provided when osq_lock() is successful
> or when osq_un
The osq_lock() and osq_unlock() function may not provide the necessary
acquire and release barrier in some cases. This patch makes sure
that the proper barriers are provided when osq_lock() is successful
or when osq_unlock() is called.
Signed-off-by: Waiman Long
---
kernel/locking/osq_lock.c |
25 matches
Mail list logo
