Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755876Ab1FFVdF (ORCPT ); Mon, 6 Jun 2011 17:33:05 -0400 Received: from mail-wy0-f174.google.com ([74.125.82.174]:43774 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752500Ab1FFVdD (ORCPT ); Mon, 6 Jun 2011 17:33:03 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=IqfBZOJ8p+8x24XvT6Y8RzUwin3XOIuyeoaoXNF/zO0fO9kwbDefBlOXqLDwDaLNA/ 1sXpWTLwP+N5N1UDQEBYAUSpJUlbj/LYbBsMtdNodfhFypHmLVyBSKOHUMrYRJtzs3r+ Xxm54KJYTwVBM8K/IpkBskExFDGBZXJIM8IZQ= Subject: Re: [PATCH/RFC] asm-generic/mutex-dec.h: add SMP support From: Eric Dumazet To: Andrew Morton Cc: Mike Frysinger , Arnd Bergmann , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, uclinux-dist-devel@blackfin.uclinux.org, Nick Piggin In-Reply-To: <20110606142301.c0a570da.akpm@linux-foundation.org> References: <1306725568-10922-1-git-send-email-vapier@gentoo.org> <20110606142301.c0a570da.akpm@linux-foundation.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 06 Jun 2011 23:32:58 +0200 Message-ID: <1307395978.2642.33.camel@edumazet-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2922 Lines: 94 Le lundi 06 juin 2011 à 14:23 -0700, Andrew Morton a écrit : > 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. > > > > Signed-off-by: Mike Frysinger > > --- > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/