From: Jack Steiner <steiner@sgi.com>
To: Nikanth Karthikesan <knikanth@suse.de>
Cc: Ingo Molnar <mingo@redhat.com>, 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>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] x86: avoid atomic operation in test_and_set_bit_lock if possible
Date: Thu, 24 Mar 2011 12:13:08 -0500 [thread overview]
Message-ID: <20110324171308.GC28825@sgi.com> (raw)
In-Reply-To: <201103241026.01624.knikanth@suse.de>
On Thu, Mar 24, 2011 at 10:26:01AM +0530, Nikanth Karthikesan wrote:
> 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>
>
Don't we also have an issue related to the coherency protocols.
If the cacheline is referenced by a test-and-set instruction and
the line does not currently reside in the local caches, it is fetched
for exclusive access using a single off-socket request.
If the code first reads the CL, then does a test-and-set, the line
may be first read in shared mode. Then a second off-socket request must be issued to
obtain exclusive access. This can be a serious issue on large systems.
If the bit is typically already set, the new code is a big win but is this
the case? I suspect not.
Do we need a new variant of test-and-set? The new variant would
first test the bit, then set it if not already set. This would be used only
in places where the bit is likely already set. The downside is that it is
frequently difficult to predict whether the bit is already set.
> ---
>
> 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 prev parent reply other threads:[~2011-03-24 17:13 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 4:56 [PATCH RFC] x86: avoid atomic operation in test_and_set_bit_lock if possible Nikanth Karthikesan
2011-03-24 8:52 ` 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 [this message]
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=20110324171308.GC28825@sgi.com \
--to=steiner@sgi.com \
--cc=JBeulich@novell.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=knikanth@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=npiggin@kernel.dk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox