[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090703180042.GA3405@elte.hu>
Date: Fri, 3 Jul 2009 20:00:42 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: mingo@...hat.com, hpa@...or.com, paulus@...ba.org, acme@...hat.com,
linux-kernel@...r.kernel.org, eric.dumazet@...il.com,
a.p.zijlstra@...llo.nl, efault@....de, arnd@...db.de,
fweisbec@...il.com, dhowells@...hat.com, akpm@...ux-foundation.org,
tglx@...utronix.de, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perfcounters/urgent] x86: atomic64: Fix unclean type use
in atomic64_xchg()
* Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Fri, 3 Jul 2009, tip-bot for Ingo Molnar wrote:
> >
> > Fix atomic64_xchg() to use __atomic64_read() instead.
>
> Hmm. The whole __atomic64_read() thing should be dropped. Are
> there any users? None of them should be valid, as Eric's numbers
> showed. It's apparently better to start out with a random value
> rather than actually trying to read it.
ah, yes.
We still have this use:
u64 atomic64_xchg(atomic64_t *ptr, u64 new_val)
{
u64 old_val;
do {
old_val = __atomic64_read(ptr);
} while (atomic64_cmpxchg(ptr, old_val, new_val) != old_val);
return old_val;
}
EXPORT_SYMBOL(atomic64_xchg);
I'm testing the commit below which improves this loop and also
removes __atomic64_read().
Ingo
---------------->
>From 2f4f497dfb708daa52392db98b4bb3d6378be3d3 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@...e.hu>
Date: Fri, 3 Jul 2009 19:56:36 +0200
Subject: [PATCH] x86: atomic64: Improve atomic64_xchg()
Remove the read-first logic from atomic64_xchg() and simplify
the loop.
This function was the last user of __atomic64_read() - remove it.
Also, change the 'real_val' assumption from the somewhat quirky
1ULL << 32 value to the (just as arbitrary, but simpler) value
of 0.
Reported-by: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Eric Dumazet <eric.dumazet@...il.com>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Mike Galbraith <efault@....de>
Cc: Paul Mackerras <paulus@...ba.org>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
Cc: Frederic Weisbecker <fweisbec@...il.com>
Cc: David Howells <dhowells@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Arnd Bergmann <arnd@...db.de>
LKML-Reference: <tip-05118ab8859492ac9ddda0154cf90e37b0a4a0b0@....kernel.org>
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
arch/x86/include/asm/atomic_32.h | 9 ---------
arch/x86/lib/atomic64_32.c | 21 +++++++++++++++------
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/atomic_32.h b/arch/x86/include/asm/atomic_32.h
index aa045de..d7c8849 100644
--- a/arch/x86/include/asm/atomic_32.h
+++ b/arch/x86/include/asm/atomic_32.h
@@ -268,15 +268,6 @@ typedef struct {
#define ATOMIC64_INIT(val) { (val) }
-/**
- * atomic64_read - read atomic64 variable
- * @ptr: pointer of type atomic64_t
- *
- * Atomically reads the value of @v.
- * Doesn't imply a read memory barrier.
- */
-#define __atomic64_read(ptr) ((ptr)->counter)
-
extern u64 atomic64_cmpxchg(atomic64_t *ptr, u64 old_val, u64 new_val);
/**
diff --git a/arch/x86/lib/atomic64_32.c b/arch/x86/lib/atomic64_32.c
index aab898c..0fac67b 100644
--- a/arch/x86/lib/atomic64_32.c
+++ b/arch/x86/lib/atomic64_32.c
@@ -31,14 +31,23 @@ EXPORT_SYMBOL(atomic64_cmpxchg);
* Atomically xchgs the value of @ptr to @new_val and returns
* the old value.
*/
-
u64 atomic64_xchg(atomic64_t *ptr, u64 new_val)
{
- u64 old_val;
+ /*
+ * Try first with a (possibly incorrect) assumption about
+ * what we have there. We'll do two loops most likely,
+ * but we'll get an ownership MESI transaction straight away
+ * instead of a read transaction followed by a
+ * flush-for-ownership transaction:
+ */
+ u64 old_val, real_val = 0;
do {
- old_val = __atomic64_read(ptr);
- } while (atomic64_cmpxchg(ptr, old_val, new_val) != old_val);
+ old_val = real_val;
+
+ real_val = atomic64_cmpxchg(ptr, old_val, new_val);
+
+ } while (real_val != old_val);
return old_val;
}
@@ -89,13 +98,13 @@ EXPORT_SYMBOL(atomic64_read);
noinline u64 atomic64_add_return(u64 delta, atomic64_t *ptr)
{
/*
- * Try first with a (probably incorrect) assumption about
+ * Try first with a (possibly incorrect) assumption about
* what we have there. We'll do two loops most likely,
* but we'll get an ownership MESI transaction straight away
* instead of a read transaction followed by a
* flush-for-ownership transaction:
*/
- u64 old_val, new_val, real_val = 1ULL << 32;
+ u64 old_val, new_val, real_val = 0;
do {
old_val = real_val;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists