From: Nikanth Karthikesan <knikanth@suse.de>
To: Ingo Molnar <mingo@redhat.com>
Cc: Nick Piggin <npiggin@kernel.dk>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
Jan Beulich <JBeulich@novell.com>, Jack Steiner <steiner@sgi.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH RFC] x86: avoid atomic operation in test_and_set_bit_lock if possible
Date: Thu, 24 Mar 2011 10:26:01 +0530 [thread overview]
Message-ID: <201103241026.01624.knikanth@suse.de> (raw)
On x86_64 SMP with lots of CPU atomic instructions which assert the LOCK #
signal can stall other CPUs. And as the number of cores increase this penalty
scales proportionately. So it is best to try and avoid atomic instructions
wherever possible. test_and_set_bit_lock() can avoid using LOCK_PREFIX if it
finds the bit set already.
Signed-off-by: Nikanth Karthikesan <knikanth@suse.de>
---
diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 903683b..26a42ff 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -203,19 +203,6 @@ static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
}
/**
- * test_and_set_bit_lock - Set a bit and return its old value for lock
- * @nr: Bit to set
- * @addr: Address to count from
- *
- * This is the same as test_and_set_bit on x86.
- */
-static __always_inline int
-test_and_set_bit_lock(int nr, volatile unsigned long *addr)
-{
- return test_and_set_bit(nr, addr);
-}
-
-/**
* __test_and_set_bit - Set a bit and return its old value
* @nr: Bit to set
* @addr: Address to count from
@@ -339,6 +326,25 @@ static int test_bit(int nr, const volatile unsigned long *addr);
: variable_test_bit((nr), (addr)))
/**
+ * test_and_set_bit_lock - Set a bit and return its old value for lock
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This is the same as test_and_set_bit on x86. But atomic operation is
+ * avoided, if the bit was already set.
+ */
+static __always_inline int
+test_and_set_bit_lock(int nr, volatile unsigned long *addr)
+{
+#ifdef CONFIG_SMP
+ barrier();
+ if (test_bit(nr, addr))
+ return 1;
+#endif
+ return test_and_set_bit(nr, addr);
+}
+
+/**
* __ffs - find first set bit in word
* @word: The word to search
*
next reply other threads:[~2011-03-24 4:59 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 4:56 Nikanth Karthikesan [this message]
2011-03-24 8:52 ` [PATCH RFC] x86: avoid atomic operation in test_and_set_bit_lock if possible Jan Beulich
2011-03-24 8:56 ` Ingo Molnar
2011-03-24 14:52 ` Borislav Petkov
2011-03-24 16:48 ` Jan Beulich
2011-03-24 17:19 ` Ingo Molnar
2011-03-25 10:06 ` Jan Beulich
2011-03-25 11:10 ` Ingo Molnar
2011-03-25 12:04 ` Nikanth Karthikesan
2011-03-25 13:12 ` Jack Steiner
2011-03-25 16:29 ` Linus Torvalds
2011-03-25 16:47 ` Jan Beulich
2011-03-25 16:49 ` Jack Steiner
2011-03-24 17:30 ` Jack Steiner
2011-03-24 20:00 ` Ingo Molnar
2011-03-24 20:40 ` Andi Kleen
2011-03-24 20:50 ` Ingo Molnar
2011-03-24 21:37 ` Andi Kleen
2011-03-24 20:48 ` Eric Dumazet
2011-03-24 20:54 ` Ingo Molnar
2011-03-24 21:02 ` Eric Dumazet
2011-03-24 21:42 ` Andi Kleen
2011-03-24 23:26 ` Linus Torvalds
2011-03-24 23:56 ` Andi Kleen
2011-03-25 5:47 ` Eric Dumazet
2011-03-25 9:32 ` Ingo Molnar
2011-03-25 9:44 ` Eric Dumazet
2011-03-25 9:59 ` Ingo Molnar
2011-03-25 10:50 ` Borislav Petkov
2011-03-25 11:10 ` Peter Zijlstra
2011-03-25 11:11 ` Ingo Molnar
2011-03-25 16:16 ` Robert Richter
2011-03-25 17:22 ` Andi Kleen
2011-03-25 19:26 ` Ingo Molnar
2011-03-25 9:38 ` Eric Dumazet
2011-03-25 20:29 ` Peter Zijlstra
2011-03-26 8:15 ` Eric Dumazet
2011-03-26 9:44 ` Peter Zijlstra
2011-03-26 9:57 ` Ingo Molnar
2011-03-25 9:22 ` Ingo Molnar
2011-03-25 10:21 ` Peter Zijlstra
2011-03-25 16:08 ` Robert Richter
2011-03-25 19:31 ` Ingo Molnar
2011-03-25 17:15 ` Andi Kleen
2011-03-25 19:21 ` Ingo Molnar
2011-03-25 9:35 ` Ingo Molnar
2011-03-24 17:01 ` Linus Torvalds
2011-03-24 17:13 ` Jack Steiner
2011-03-24 18:38 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201103241026.01624.knikanth@suse.de \
--to=knikanth@suse.de \
--cc=JBeulich@novell.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=npiggin@kernel.dk \
--cc=steiner@sgi.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.