From: "H. Peter Anvin" <hpa@zytor.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Christoph Lameter <cl@linux.com>, Tejun Heo <tj@kernel.org>,
akpm@linux-foundation.org, Pekka Enberg <penberg@cs.helsinki.fi>,
linux-kernel@vger.kernel.org,
Eric Dumazet <eric.dumazet@gmail.com>,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: [cpuops cmpxchg V1 2/4] x86: this_cpu_cmpxchg and this_cpu_xchg operations
Date: Wed, 08 Dec 2010 22:26:59 -0800 [thread overview]
Message-ID: <4D0076B3.9090106@zytor.com> (raw)
In-Reply-To: <20101208181736.GC30693@Krystal>
On 12/08/2010 10:17 AM, Mathieu Desnoyers wrote:
>
> Hi Christoph,
>
> Can you show if this provides savings in terms of:
>
> - instruction cache footprint
> - cycles required to run
> - large-scale impact on the branch prediction buffers
>
> Given that this targets per-cpu data only, the additional impact on cache-line
> exchange traffic of using cmpxchg over xchg (cache-line not grabbed as exclusive
> by the initial read) should not really matter.
>
> I'm CCing Arjan and HPA, because they might have some interesting insight into
> the performance impact of lock-prefixed xchg vs using local cmpxchg in a loop.
>
XCHG is always locked; it doesn't need the prefix. Unfortunately,
unlike on the 8086 on modern processors locks have a real cost.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
next prev parent reply other threads:[~2010-12-09 6:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-08 17:55 [cpuops cmpxchg V1 0/4] Cmpxchg and xchg operations Christoph Lameter
2010-12-08 17:55 ` [cpuops cmpxchg V1 1/4] percpu: Generic this_cpu_cmpxchg() and this_cpu_xchg support Christoph Lameter
2010-12-08 17:55 ` [cpuops cmpxchg V1 2/4] x86: this_cpu_cmpxchg and this_cpu_xchg operations Christoph Lameter
2010-12-08 18:08 ` Christoph Lameter
2010-12-08 18:17 ` Mathieu Desnoyers
2010-12-09 6:26 ` H. Peter Anvin [this message]
2010-12-09 23:40 ` Christoph Lameter
2010-12-08 22:20 ` Christoph Lameter
2010-12-08 17:55 ` [cpuops cmpxchg V1 3/4] irq_work: Use per cpu atomics instead of regular atomics Christoph Lameter
2010-12-08 17:55 ` [cpuops cmpxchg V1 4/4] vmstat: User per cpu atomics to avoid interrupt disable / enable Christoph Lameter
2010-12-08 22:22 ` cpuops cmpxchg: Provide 64 bit this_cpu_xx for 32 bit x86 using cmpxchg8b Christoph Lameter
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=4D0076B3.9090106@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=cl@linux.com \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=penberg@cs.helsinki.fi \
--cc=tj@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.