From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: Oliver Neukum <oliver@neukum.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
David Howells <dhowells@redhat.com>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Uses for memory barriers
Date: Mon, 11 Sep 2006 13:29:08 -0700 [thread overview]
Message-ID: <20060911202908.GF1295@us.ibm.com> (raw)
In-Reply-To: <200609112148.42302.oliver@neukum.org>
On Mon, Sep 11, 2006 at 09:48:42PM +0200, Oliver Neukum wrote:
> Am Montag, 11. September 2006 18:21 schrieb Paul E. McKenney:
> > 1. A given CPU will always perceive its own memory operations
> > as occuring in program order.
>
> Is this true for physical memory if virtually indexed caches are
> involved?
As I understand it, in systems with virtually indexed caches, the OS must
take care to ensure that a given cacheline appears only once in the cache,
even if it is mapped to multiple virtual addresses. If an OS failed to
do this, then, as far as I can see, all bets are off. Curt Schimmel's
book "UNIX(R) Systems for Modern Architectures: Symmetric Multiprocessing
and Caching for Kernel Programmers" is an excellent guide to the issues
posed by virtually indexed and virtually tagged caches.
In principle, one could construct a virtually indexed/tagged CPU cache
that automatically ejected any line with a conflicting physical address
(given that lookups are presumably much more frequent than loading new
cache lines), but I have no idea if any real hardware takes this approach.
I have had the good fortune to always work with physically tagged/indexed
caches. ;-)
Thanx, Paul
next prev parent reply other threads:[~2006-09-11 20:28 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200609082230.22225.oliver@neukum.org>
2006-09-08 21:26 ` Uses for memory barriers Alan Stern
2006-09-08 21:46 ` Oliver Neukum
2006-09-08 22:25 ` Alan Stern
2006-09-08 22:49 ` Oliver Neukum
2006-09-09 2:25 ` Alan Stern
2006-09-11 16:21 ` Paul E. McKenney
2006-09-11 16:50 ` Alan Stern
2006-09-11 17:23 ` Segher Boessenkool
2006-09-11 19:04 ` Paul E. McKenney
2006-09-11 19:03 ` Paul E. McKenney
2006-09-11 17:21 ` Segher Boessenkool
2006-09-11 19:48 ` Oliver Neukum
2006-09-11 20:29 ` Paul E. McKenney [this message]
2006-09-12 9:01 ` David Howells
2006-09-12 10:22 ` Oliver Neukum
2006-09-12 14:55 ` Paul E. McKenney
2006-09-12 15:07 ` Oliver Neukum
2006-09-12 16:12 ` Paul E. McKenney
2006-09-12 17:50 ` Segher Boessenkool
2006-09-12 14:42 ` Paul E. McKenney
2006-09-12 8:57 ` David Howells
[not found] <20060911190005.GA1295@us.ibm.com>
2006-09-12 18:08 ` Alan Stern
2006-09-12 20:23 ` Paul E. McKenney
2006-09-14 14:58 ` Alan Stern
2006-09-15 5:16 ` Paul E. McKenney
2006-09-15 19:48 ` Alan Stern
2006-09-16 4:19 ` Paul E. McKenney
2006-09-16 15:28 ` Alan Stern
2006-09-18 19:13 ` Paul E. McKenney
2006-09-18 20:13 ` Alan Stern
2006-09-19 0:47 ` Paul E. McKenney
2006-09-19 16:04 ` Alan Stern
2006-09-19 16:38 ` Nick Piggin
2006-09-19 17:40 ` Alan Stern
2006-09-19 17:51 ` Nick Piggin
2006-09-19 18:19 ` Paul E. McKenney
2006-09-19 18:48 ` Nick Piggin
2006-09-19 19:36 ` Paul E. McKenney
2006-09-19 19:48 ` Nick Piggin
2006-09-19 20:01 ` Paul E. McKenney
2006-09-19 20:38 ` Alan Stern
2006-09-21 1:43 ` Paul E. McKenney
2006-09-19 18:16 ` Paul E. McKenney
2006-09-20 19:39 ` Alan Stern
2006-09-21 1:34 ` Paul E. McKenney
2006-09-21 20:59 ` Alan Stern
2006-09-22 5:02 ` Paul E. McKenney
2006-09-22 20:38 ` Alan Stern
2006-09-27 21:06 ` Alan Stern
2006-09-30 1:11 ` Paul E. McKenney
2006-09-30 21:01 ` Alan Stern
2006-10-02 0:06 ` Paul E. McKenney
2006-10-02 15:44 ` Alan Stern
2006-10-04 15:35 ` Paul E. McKenney
2006-10-04 18:04 ` Alan Stern
2006-10-13 16:51 ` Paul E. McKenney
2006-10-13 18:30 ` Alan Stern
2006-10-13 22:39 ` Paul E. McKenney
2006-10-14 2:27 ` Alan Stern
2006-10-17 1:24 ` Paul E. McKenney
2006-10-17 15:29 ` Alan Stern
2006-10-17 17:27 ` Paul E. McKenney
2006-10-17 19:42 ` Alan Stern
2006-10-17 20:15 ` Paul E. McKenney
2006-10-17 21:21 ` Alan Stern
2006-10-17 22:58 ` Paul E. McKenney
2006-10-18 19:05 ` Alan Stern
2006-10-18 23:01 ` Paul E. McKenney
2006-10-19 16:44 ` Alan Stern
2006-10-19 19:21 ` Paul E. McKenney
2006-10-19 20:55 ` Alan Stern
2006-10-19 22:46 ` Paul E. McKenney
2006-10-20 16:54 ` Alan Stern
2006-10-21 0:59 ` Paul E. McKenney
2006-10-21 19:47 ` Alan Stern
2006-10-21 22:52 ` Paul E. McKenney
2006-10-22 2:18 ` Alan Stern
2006-10-23 5:32 ` Paul E. McKenney
2006-10-23 14:07 ` Alan Stern
2006-10-24 17:52 ` Paul E. McKenney
[not found] <200609081929.33027.oliver@neukum.org>
2006-09-08 18:06 ` Alan Stern
2006-09-08 18:22 ` Oliver Neukum
2006-09-07 21:25 Alan Stern
2006-09-07 22:10 ` linux-os (Dick Johnson)
2006-09-08 18:39 ` Alan Stern
2006-09-08 0:14 ` Paul E. McKenney
2006-09-08 15:55 ` Alan Stern
2006-09-08 18:57 ` Paul E. McKenney
2006-09-08 21:23 ` Alan Stern
2006-09-09 0:44 ` Paul E. McKenney
2006-09-11 16:05 ` Alan Stern
2006-09-08 5:52 ` David Schwartz
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=20060911202908.GF1295@us.ibm.com \
--to=paulmck@us.ibm.com \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver@neukum.org \
--cc=stern@rowland.harvard.edu \
/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.