On Mon, 2012-08-13 at 15:11 +0100, Will Deacon wrote:
>
> > Will you carry this through the ARM tree or do you want me/Ingo to take
> > it?
>
> Please can you guys take it? The move to mutex-dec can go through the ARM
> tree but it's probably best if you take the core change.
OK, done. Thanks!
On Mon, Aug 13, 2012 at 03:05:17PM +0100, Peter Zijlstra wrote:
> Acked-by: Peter Zijlstra
Thanks Peter.
> Will you carry this through the ARM tree or do you want me/Ingo to take
> it?
Please can you guys take it? The move to mutex-dec can go through the ARM
tree but it's probably best if you t
On Mon, 2012-08-13 at 09:35 -0400, Nicolas Pitre wrote:
> Date: Fri, 10 Aug 2012 15:22:09 +0100
> From: Will Deacon
> Subject: [PATCH] mutex: place lock in contended state after fastpath_lock
> failure
>
> ARM recently moved to asm-generic/mutex-xchg.h for its mutex
> implementation after the pr
On Mon, 13 Aug 2012, Peter Zijlstra wrote:
> OK, I like this.. Thanks guys! Will will you send a final and complete
> patch?
Here it is:
--- >8
Date: Fri, 10 Aug 2012 15:22:09 +0100
From: Will Deacon
Subject: [PATCH] mutex: place lock in contended state after fastpath_lock
failure
ARM recent
Hi Peter,
On Mon, Aug 13, 2012 at 09:15:04AM +0100, Peter Zijlstra wrote:
> On Thu, 2012-08-09 at 12:57 -0400, Nicolas Pitre wrote:
> >
> > In other words, I think this should look like this:
> >
> > diff --git a/include/asm-generic/mutex-xchg.h
> > b/include/asm-generic/mutex-xchg.h
> > index
On Thu, 2012-08-09 at 12:57 -0400, Nicolas Pitre wrote:
>
> In other words, I think this should look like this:
>
> diff --git a/include/asm-generic/mutex-xchg.h
> b/include/asm-generic/mutex-xchg.h
> index 580a6d35c7..44a66c99c8 100644
> --- a/include/asm-generic/mutex-xchg.h
> +++ b/include/as
On Thu, 9 Aug 2012, Will Deacon wrote:
> On Thu, Aug 09, 2012 at 07:09:02PM +0100, Nicolas Pitre wrote:
> > On Thu, 9 Aug 2012, Will Deacon wrote:
> > > On Thu, Aug 09, 2012 at 05:57:33PM +0100, Nicolas Pitre wrote:
> > > > On Thu, 9 Aug 2012, Nicolas Pitre wrote:
> > > > diff --git a/include/asm-
On Thu, Aug 09, 2012 at 07:09:02PM +0100, Nicolas Pitre wrote:
> On Thu, 9 Aug 2012, Will Deacon wrote:
> > On Thu, Aug 09, 2012 at 05:57:33PM +0100, Nicolas Pitre wrote:
> > > On Thu, 9 Aug 2012, Nicolas Pitre wrote:
> > > diff --git a/include/asm-generic/mutex-xchg.h
> > > b/include/asm-generic/
On Thu, 9 Aug 2012, Will Deacon wrote:
> On Thu, Aug 09, 2012 at 05:57:33PM +0100, Nicolas Pitre wrote:
> > On Thu, 9 Aug 2012, Nicolas Pitre wrote:
> > > Yes, that looks fine. I'd remove that if (prev < 0) entirely though.
> > > We'll just swap a 0 for a 0 if the count wasn't < 0, or a 0 for a
On Thu, Aug 09, 2012 at 05:57:33PM +0100, Nicolas Pitre wrote:
> On Thu, 9 Aug 2012, Nicolas Pitre wrote:
> > Yes, that looks fine. I'd remove that if (prev < 0) entirely though.
> > We'll just swap a 0 for a 0 if the count wasn't < 0, or a 0 for a 1 if
> > the mutex just got unlocked which is
On Thu, 9 Aug 2012, Nicolas Pitre wrote:
> On Thu, 9 Aug 2012, Will Deacon wrote:
>
> > I think we could actually fix this entirely in mutex-xchg.h by doing
> > something in fastpath_lock similar to what we do for trylock:
> >
> >
> > diff --git a/include/asm-generic/mutex-xchg.h
> > b/include
On Thu, 9 Aug 2012, Will Deacon wrote:
> I think we could actually fix this entirely in mutex-xchg.h by doing
> something in fastpath_lock similar to what we do for trylock:
>
>
> diff --git a/include/asm-generic/mutex-xchg.h
> b/include/asm-generic/mutex-xchg.h
> index 580a6d3..c082e99 100644
Hi Nicolas,
Thanks for the replies.
On Thu, Aug 09, 2012 at 06:12:15AM +0100, Nicolas Pitre wrote:
> On Tue, 7 Aug 2012, Will Deacon wrote:
> > diff --git a/kernel/mutex.c b/kernel/mutex.c
> > index a307cc9..27b7887 100644
> > --- a/kernel/mutex.c
> > +++ b/kernel/mutex.c
> > @@ -170,7 +170,7 @@
On Tue, 7 Aug 2012, Will Deacon wrote:
> Hello,
>
> ARM recently moved to asm-generic/mutex-xchg.h for its mutex implementation
> after our previous implementation was found to be missing some crucial
> memory barriers. However, I'm seeing some problems running hackbench on
> SMP platforms due to
On Tue, 7 Aug 2012, Will Deacon wrote:
> On Tue, Aug 07, 2012 at 06:14:36PM +0100, Nicolas Pitre wrote:
> > On Tue, 7 Aug 2012, Will Deacon wrote:
> > > The symptoms are that a bunch of hackbench tasks are left waiting on an
> > > unlocked mutex and therefore never get woken up to claim it. I thin
On Tue, 7 Aug 2012, Will Deacon wrote:
> Hello,
>
> ARM recently moved to asm-generic/mutex-xchg.h for its mutex implementation
> after our previous implementation was found to be missing some crucial
> memory barriers. However, I'm seeing some problems running hackbench on
> SMP platforms due to
On Tue, Aug 07, 2012 at 06:33:44PM +0100, Will Deacon wrote:
> What I think is happening is that B writes the -1 in __mutex_lock_common
> and, after seeing a NULL owner (C may not have set that yet), drops through
> to the:
>
> if (atomic_xchg(&lock->count, -1) == 1)
> goto don
On Tue, Aug 07, 2012 at 06:14:36PM +0100, Nicolas Pitre wrote:
> On Tue, 7 Aug 2012, Will Deacon wrote:
> > The symptoms are that a bunch of hackbench tasks are left waiting on an
> > unlocked mutex and therefore never get woken up to claim it. I think this
> > boils down to the following sequence:
On Tue, Aug 07, 2012 at 02:48:42PM +0100, Peter Zijlstra wrote:
> On Tue, 2012-08-07 at 12:56 +0100, Will Deacon wrote:
> > ARM recently moved to asm-generic/mutex-xchg.h for its mutex implementation
> > after our previous implementation was found to be missing some crucial
> > memory barriers.
>
On Tue, 2012-08-07 at 12:56 +0100, Will Deacon wrote:
> Hello,
>
> ARM recently moved to asm-generic/mutex-xchg.h for its mutex implementation
> after our previous implementation was found to be missing some crucial
> memory barriers.
This is a76d7bd96d ("ARM: 7467/1: mutex: use generic xchg-ba
Hello,
ARM recently moved to asm-generic/mutex-xchg.h for its mutex implementation
after our previous implementation was found to be missing some crucial
memory barriers. However, I'm seeing some problems running hackbench on
SMP platforms due to the way in which the MUTEX_SPIN_ON_OWNER code opera
21 matches
Mail list logo
