From: Borislav Petkov <bp@amd64.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Nikanth Karthikesan <knikanth@suse.de>,
Ingo Molnar <mingo@redhat.com>, Nick Piggin <npiggin@kernel.dk>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"x86@kernel.org" <x86@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Beulich <JBeulich@novell.com>, Jack Steiner <steiner@sgi.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH RFC] x86: avoid atomic operation in test_and_set_bit_lock if possible
Date: Thu, 24 Mar 2011 15:52:21 +0100 [thread overview]
Message-ID: <20110324145221.GC31194@aftab> (raw)
In-Reply-To: <20110324085647.GI30812@elte.hu>
On Thu, Mar 24, 2011 at 04:56:47AM -0400, Ingo Molnar wrote:
>
> * Nikanth Karthikesan <knikanth@suse.de> 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>
[..]
> > + * 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);
> > +}
>
> On modern x86 CPUs there's no "#LOCK signal" anymore - it's replaced
> by a M[O]ESI cache coherency bus. I'd expect modern x86 CPUs to be
> pretty fast when the cacheline is local and the bit is set already.
Correct. However, LOCK still could have some overhead associated with it
and avoiding it by using only an non-atomic op (test_bit()) could bring
some miniscule speedup...
> So you really need to back up your patch with actual hard numbers.
> Putting this code into user-space and using pthreads to loop on
> the same global variable and testing the before/after effect would
> be sufficient i think. You can use 'perf stat --repeat 10' kind of
> measurements to see whether there's any improvement larger than the
> noise of the measurement.
and Ingo's question is right on the money - is this speedup noticeable
or does it simply disappear in the noise?
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
next prev parent reply other threads:[~2011-03-24 14:52 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 [this message]
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=20110324145221.GC31194@aftab \
--to=bp@amd64.org \
--cc=JBeulich@novell.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=knikanth@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=npiggin@kernel.dk \
--cc=steiner@sgi.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--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