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

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

[Mike Frysinger]

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

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
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

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

[Arnd Bergmann]

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 <vapier@gentoo.org>
> ---
> 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

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

[Andrew Morton]

On Sun, 29 May 2011 23:19:28 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> To make these guys work on SMP systems, we just need to sprinkle a few
> barriers around.
> 
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> ---
> 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.

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

[Mike Frysinger]

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

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

[Eric Dumazet]

Le lundi 06 juin 2011 à 14:23 -0700, Andrew Morton a écrit :
> On Sun, 29 May 2011 23:19:28 -0400
> Mike Frysinger <vapier@gentoo.org> wrote:
> 
> > To make these guys work on SMP systems, we just need to sprinkle a few
> > barriers around.
> > 
> > Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> > ---
> > 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.

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

[Mike Frysinger]

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