From: Keir Fraser <keir@xensource.com>
To: Zachary Amsden <zach@vmware.com>, "H. Peter Anvin" <hpa@zytor.com>
Cc: Andrew Morton <akpm@osdl.org>, Andi Kleen <ak@muc.de>,
Virtualization Mailing List <virtualization@lists.osdl.org>,
Chris Wright <chrisw@sous-sol.org>,
David Rientjes <rientjes@google.com>,
Hugh Dickins <hugh@veritas.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] i386 - pte update optimizations
Date: Fri, 13 Apr 2007 10:31:49 +0100 [thread overview]
Message-ID: <C2450C95.D3F6%keir@xensource.com> (raw)
In-Reply-To: <461EE9E5.6060403@vmware.com>
On 13/4/07 03:24, "Zachary Amsden" <zach@vmware.com> wrote:
>> You do know that P6 and higher don't do locked bus references as long
>> as the value is in the cache, right?
>
> Yes. Even then, last time I clocked instructions, xchg was still slower
> than read / write, although I could be misremembering. And it's not
> totally clear that they will always be in cached state, however, and for
> SMP, we still want to drop the implicit lock in cases where the
> processor might not know they are cached exclusive, but we know there
> are no other racing users. And there are plenty of old processors out
> there to still make it worthwhile.
LOCKed instruction suck really badly on the netburst microarchitecture (like
factor of 10x, or not far off). I think it's probably because of their side
effect of serialising memory accesses, causing horrible pipeline stalls.
-- Keir
next prev parent reply other threads:[~2007-04-13 9:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-12 5:30 [PATCH 0/4] i386 - pte update optimizations Zachary Amsden
2007-04-13 1:25 ` H. Peter Anvin
2007-04-13 1:25 ` H. Peter Anvin
2007-04-13 2:24 ` Zachary Amsden
2007-04-13 6:00 ` Eric Dumazet
2007-04-13 6:25 ` H. Peter Anvin
2007-04-13 9:31 ` Keir Fraser [this message]
2007-04-13 12:27 ` Andi Kleen
2007-04-13 11:31 ` Keir Fraser
2007-04-13 15:34 ` H. Peter Anvin
2007-04-13 15:34 ` H. Peter Anvin
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=C2450C95.D3F6%keir@xensource.com \
--to=keir@xensource.com \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=chrisw@sous-sol.org \
--cc=hpa@zytor.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rientjes@google.com \
--cc=virtualization@lists.osdl.org \
--cc=zach@vmware.com \
/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.