2011-05-30 03:14:31

by Mike Frysinger

[permalink] [raw]
Subject: [PATCH/RFC] asm-generic/mutex-dec.h: add SMP support

To make these guys work on SMP systems, we just need to sprinkle a few
barriers around.

Signed-off-by: Mike Frysinger <[email protected]>
---
note: this is what the Blackfin SMP port is using, but it doesn't seem
like other SMP ports are ... so I wonder if we're just trying too hard
and these barriers aren't actually necessary ?

include/asm-generic/mutex-dec.h | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/include/asm-generic/mutex-dec.h b/include/asm-generic/mutex-dec.h
index f104af7..e746c3c 100644
--- a/include/asm-generic/mutex-dec.h
+++ b/include/asm-generic/mutex-dec.h
@@ -22,6 +22,8 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *))
{
if (unlikely(atomic_dec_return(count) < 0))
fail_fn(count);
+ else
+ smp_mb();
}

/**
@@ -39,6 +41,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
{
if (unlikely(atomic_dec_return(count) < 0))
return fail_fn(count);
+ smp_mb();
return 0;
}

@@ -58,6 +61,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
static inline void
__mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *))
{
+ smp_mb();
if (unlikely(atomic_inc_return(count) <= 0))
fail_fn(count);
}
@@ -82,8 +86,10 @@ __mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *))
static inline int
__mutex_fastpath_trylock(atomic_t *count, int (*fail_fn)(atomic_t *))
{
- if (likely(atomic_cmpxchg(count, 1, 0) == 1))
+ if (likely(atomic_cmpxchg(count, 1, 0) == 1)) {
+ smp_mb();
return 1;
+ }
return 0;
}

--
1.7.5.rc3


2011-05-30 07:00:19

by Arnd Bergmann

[permalink] [raw]
Subject: Re: [PATCH/RFC] asm-generic/mutex-dec.h: add SMP support

On Monday 30 May 2011 05:19:28 Mike Frysinger wrote:
> To make these guys work on SMP systems, we just need to sprinkle a few
> barriers around.
>
> Signed-off-by: Mike Frysinger <[email protected]>
> ---
> note: this is what the Blackfin SMP port is using, but it doesn't seem
> like other SMP ports are ... so I wonder if we're just trying too hard
> and these barriers aren't actually necessary ?

On some architectures, atomic instructions are implicit barriers. On
others, the cmpxchg() macro contains a barrier. I'm not sure if there
is other code relying on that.

Arnd

2011-06-06 21:23:49

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCH/RFC] asm-generic/mutex-dec.h: add SMP support

On Sun, 29 May 2011 23:19:28 -0400
Mike Frysinger <[email protected]> wrote:

> To make these guys work on SMP systems, we just need to sprinkle a few
> barriers around.
>
> Signed-off-by: Mike Frysinger <[email protected]>
> ---
> note: this is what the Blackfin SMP port is using, but it doesn't seem
> like other SMP ports are ... so I wonder if we're just trying too hard
> and these barriers aren't actually necessary ?
>
> include/asm-generic/mutex-dec.h | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/include/asm-generic/mutex-dec.h b/include/asm-generic/mutex-dec.h
> index f104af7..e746c3c 100644
> --- a/include/asm-generic/mutex-dec.h
> +++ b/include/asm-generic/mutex-dec.h
> @@ -22,6 +22,8 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *))
> {
> if (unlikely(atomic_dec_return(count) < 0))
> fail_fn(count);
> + else
> + smp_mb();
> }
>
> /**
> @@ -39,6 +41,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
> {
> if (unlikely(atomic_dec_return(count) < 0))
> return fail_fn(count);
> + smp_mb();
> return 0;
> }
>
> @@ -58,6 +61,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
> static inline void
> __mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *))
> {
> + smp_mb();
> if (unlikely(atomic_inc_return(count) <= 0))
> fail_fn(count);
> }
> @@ -82,8 +86,10 @@ __mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *))
> static inline int
> __mutex_fastpath_trylock(atomic_t *count, int (*fail_fn)(atomic_t *))
> {
> - if (likely(atomic_cmpxchg(count, 1, 0) == 1))
> + if (likely(atomic_cmpxchg(count, 1, 0) == 1)) {
> + smp_mb();
> return 1;
> + }
> return 0;
> }

This patch basically reverts Nick's a8ddac7e53e89cb ("mutex: speed up
generic mutex implementations"). What's up with that?

I could try to review this patch but I'm pathetic with barriers. Help.

2011-06-06 21:31:32

by Mike Frysinger

[permalink] [raw]
Subject: Re: [uclinux-dist-devel] [PATCH/RFC] asm-generic/mutex-dec.h: add SMP support

On Mon, Jun 6, 2011 at 17:23, Andrew Morton wrote:
> On Sun, 29 May 2011 23:19:28 -0400 Mike Frysinger wrote:
>> To make these guys work on SMP systems, we just need to sprinkle a few
>> barriers around.
>>
>> diff --git a/include/asm-generic/mutex-dec.h b/include/asm-generic/mutex-dec.h
>> index f104af7..e746c3c 100644
>> --- a/include/asm-generic/mutex-dec.h
>> +++ b/include/asm-generic/mutex-dec.h
>> @@ -22,6 +22,8 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *))
>>  {
>>       if (unlikely(atomic_dec_return(count) < 0))
>>               fail_fn(count);
>> +     else
>> +             smp_mb();
>>  }
>>
>>  /**
>> @@ -39,6 +41,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
>>  {
>>       if (unlikely(atomic_dec_return(count) < 0))
>>               return fail_fn(count);
>> +     smp_mb();
>>       return 0;
>>  }
>>
>> @@ -58,6 +61,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
>>  static inline void
>>  __mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *))
>>  {
>> +     smp_mb();
>>       if (unlikely(atomic_inc_return(count) <= 0))
>>               fail_fn(count);
>>  }
>> @@ -82,8 +86,10 @@ __mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *))
>>  static inline int
>>  __mutex_fastpath_trylock(atomic_t *count, int (*fail_fn)(atomic_t *))
>>  {
>> -     if (likely(atomic_cmpxchg(count, 1, 0) == 1))
>> +     if (likely(atomic_cmpxchg(count, 1, 0) == 1)) {
>> +             smp_mb();
>>               return 1;
>> +     }
>>       return 0;
>>  }
>
> This patch basically reverts Nick's a8ddac7e53e89cb ("mutex: speed up
> generic mutex implementations").  What's up with that?
>
> I could try to review this patch but I'm pathetic with barriers.  Help.

thanks for that tip. i think we can chalk this patch up to the
origins of the Blackfin SMP port ... it branched this code before
Nick's patch, and never incorporated common changes back. so i'll
just drop it once i boot up a system to double check and convert the
Blackfin code over to the asm-generic version completely to avoid
future issues.
-mike

2011-06-06 21:33:05

by Eric Dumazet

[permalink] [raw]
Subject: Re: [PATCH/RFC] asm-generic/mutex-dec.h: add SMP support

Le lundi 06 juin 2011 à 14:23 -0700, Andrew Morton a écrit :
> On Sun, 29 May 2011 23:19:28 -0400
> Mike Frysinger <[email protected]> wrote:
>
> > To make these guys work on SMP systems, we just need to sprinkle a few
> > barriers around.
> >
> > Signed-off-by: Mike Frysinger <[email protected]>
> > ---
> > note: this is what the Blackfin SMP port is using, but it doesn't seem
> > like other SMP ports are ... so I wonder if we're just trying too hard
> > and these barriers aren't actually necessary ?
> >
> > include/asm-generic/mutex-dec.h | 8 +++++++-
> > 1 files changed, 7 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/asm-generic/mutex-dec.h b/include/asm-generic/mutex-dec.h
> > index f104af7..e746c3c 100644
> > --- a/include/asm-generic/mutex-dec.h
> > +++ b/include/asm-generic/mutex-dec.h
> > @@ -22,6 +22,8 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *))
> > {
> > if (unlikely(atomic_dec_return(count) < 0))
> > fail_fn(count);

Check Documentation/memory-barriers.txt, around line 1688

atomic_dec_return() implies a full memory barrier on each side of the
operation.

smp_mb() is therefore not needed here


> > + else
> > + smp_mb();
> > }
> >
> > /**
> > @@ -39,6 +41,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
> > {
> > if (unlikely(atomic_dec_return(count) < 0))
> > return fail_fn(count);
> > + smp_mb();

atomic_dec_return() implies a full memory barrier.
smp_mb() is therefore not needed here

> > return 0;
> > }
> >
> > @@ -58,6 +61,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
> > static inline void
> > __mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *))
> > {
> > + smp_mb();

atomic_inc_return() implies a full memory barrier.
smp_mb() is therefore not needed here


> > if (unlikely(atomic_inc_return(count) <= 0))
> > fail_fn(count);
> > }
> > @@ -82,8 +86,10 @@ __mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *))
> > static inline int
> > __mutex_fastpath_trylock(atomic_t *count, int (*fail_fn)(atomic_t *))
> > {
> > - if (likely(atomic_cmpxchg(count, 1, 0) == 1))
> > + if (likely(atomic_cmpxchg(count, 1, 0) == 1)) {
> > + smp_mb();

atomic_cmpxchg() implies a full memory barrier.
smp_mb() is therefore not needed here


> > return 1;
> > + }
> > return 0;
> > }
>
> This patch basically reverts Nick's a8ddac7e53e89cb ("mutex: speed up
> generic mutex implementations"). What's up with that?
>
> I could try to review this patch but I'm pathetic with barriers. Help.

Well, I really dont understand this patch, it makes no sense.


2011-06-06 22:34:08

by Mike Frysinger

[permalink] [raw]
Subject: Re: [uclinux-dist-devel] [PATCH/RFC] asm-generic/mutex-dec.h: add SMP support

On Mon, Jun 6, 2011 at 17:31, Mike Frysinger wrote:
> On Mon, Jun 6, 2011 at 17:23, Andrew Morton wrote:
>> On Sun, 29 May 2011 23:19:28 -0400 Mike Frysinger wrote:
>>> To make these guys work on SMP systems, we just need to sprinkle a few
>>> barriers around.
>>>
>>> diff --git a/include/asm-generic/mutex-dec.h b/include/asm-generic/mutex-dec.h
>>> index f104af7..e746c3c 100644
>>> --- a/include/asm-generic/mutex-dec.h
>>> +++ b/include/asm-generic/mutex-dec.h
>>> @@ -22,6 +22,8 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *))
>>>  {
>>>       if (unlikely(atomic_dec_return(count) < 0))
>>>               fail_fn(count);
>>> +     else
>>> +             smp_mb();
>>>  }
>>>
>>>  /**
>>> @@ -39,6 +41,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
>>>  {
>>>       if (unlikely(atomic_dec_return(count) < 0))
>>>               return fail_fn(count);
>>> +     smp_mb();
>>>       return 0;
>>>  }
>>>
>>> @@ -58,6 +61,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
>>>  static inline void
>>>  __mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *))
>>>  {
>>> +     smp_mb();
>>>       if (unlikely(atomic_inc_return(count) <= 0))
>>>               fail_fn(count);
>>>  }
>>> @@ -82,8 +86,10 @@ __mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *))
>>>  static inline int
>>>  __mutex_fastpath_trylock(atomic_t *count, int (*fail_fn)(atomic_t *))
>>>  {
>>> -     if (likely(atomic_cmpxchg(count, 1, 0) == 1))
>>> +     if (likely(atomic_cmpxchg(count, 1, 0) == 1)) {
>>> +             smp_mb();
>>>               return 1;
>>> +     }
>>>       return 0;
>>>  }
>>
>> This patch basically reverts Nick's a8ddac7e53e89cb ("mutex: speed up
>> generic mutex implementations").  What's up with that?
>>
>> I could try to review this patch but I'm pathetic with barriers.  Help.
>
> thanks for that tip.  i think we can chalk this patch up to the
> origins of the Blackfin SMP port ... it branched this code before
> Nick's patch, and never incorporated common changes back.  so i'll
> just drop it once i boot up a system to double check and convert the
> Blackfin code over to the asm-generic version completely to avoid
> future issues.

seems to be ok (and our core atomic's do include barriers themselves),
so let's just drop this patch on the floor and forget about it.
thanks all!
-mike