Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932101Ab3CLCPo (ORCPT ); Mon, 11 Mar 2013 22:15:44 -0400 Received: from mail-vc0-f178.google.com ([209.85.220.178]:59379 "EHLO mail-vc0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754571Ab3CLCPn (ORCPT ); Mon, 11 Mar 2013 22:15:43 -0400 MIME-Version: 1.0 In-Reply-To: References: <1362843501-31159-1-git-send-email-tom.leiming@gmail.com> Date: Tue, 12 Mar 2013 10:15:42 +0800 Message-ID: Subject: Re: [PATCH] atomic: improve atomic_inc_unless_negative/atomic_dec_unless_positive From: Ming Lei To: Frederic Weisbecker Cc: Andrew Morton , linux-kernel@vger.kernel.org, Shaohua Li , Al Viro , Paul McKenney Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2693 Lines: 68 On Tue, Mar 12, 2013 at 7:59 AM, Frederic Weisbecker wrote: > 2013/3/9 Ming Lei : >> Generally, both atomic_inc_unless_negative() and >> atomic_dec_unless_positive() need at least two atomic_cmpxchg() >> to complete the atomic operation. In fact, the 1st atomic_cmpxchg() >> is just used to read current value of the atomic variable at most times. >> >> Considered memory barrier, bus lock, cache walking, etc. things may be >> involved in atomic_cmpxchg(), it is much expensive than atomic_read(), >> which is just the simple below: >> >> (*(volatile int *)&(v)->counter) >> >> so this patch can save one extra atomic_cmpxchg() for the two >> helpers under general situation, and should improve them a bit. >> >> Cc: Andrew Morton >> Cc: Shaohua Li >> Cc: Al Viro >> Signed-off-by: Ming Lei >> --- >> include/linux/atomic.h | 28 ++++++++++++++++++---------- >> 1 file changed, 18 insertions(+), 10 deletions(-) >> >> diff --git a/include/linux/atomic.h b/include/linux/atomic.h >> index 5b08a85..aa951d8 100644 >> --- a/include/linux/atomic.h >> +++ b/include/linux/atomic.h >> @@ -63,26 +63,34 @@ static inline int atomic_inc_not_zero_hint(atomic_t *v, int hint) >> #ifndef atomic_inc_unless_negative >> static inline int atomic_inc_unless_negative(atomic_t *p) >> { >> - int v, v1; >> - for (v = 0; v >= 0; v = v1) { >> - v1 = atomic_cmpxchg(p, v, v + 1); >> - if (likely(v1 == v)) >> + int v, t; >> + >> + v = atomic_read(p); >> + while (1) { >> + if (unlikely(v < 0)) >> + return 0; > > But atomic_read() lacks the full memory barrier that is needed for > proper atomicity here. > > For example if the initial value of p is -1 and another CPU just did > an atomic_inc() that resulted in the new value to be 0, the above > atomic_read() might return -1 because there is no guarantee it's > seeing the recent update on the remote CPU. Yes, you are right. Also looks memory barrier is needed around atomic_inc() too. But I have a question, why a memory barrier can guarantee that remote CPU can see the recent update? I understand that memory barrier only orders consecutive memory access, and but here not see this kind of pattern. Sorry for a possibly stupid question. Thanks, -- Ming Lei -- 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/