From: Nick Piggin <nickpiggin@yahoo.com.au>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@osdl.org, akpm@osdl.org, mingo@redhat.com,
alan@redhat.com, linux-arch@vger.kernel.org,
linuxppc64-dev@ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Document Linux's memory barriers [try #4]
Date: Fri, 10 Mar 2006 16:28:51 +1100 [thread overview]
Message-ID: <44110E93.8060504@yahoo.com.au> (raw)
In-Reply-To: <16835.1141936162@warthog.cambridge.redhat.com>
David Howells wrote:
> +==========================
> +WHAT IS CONSIDERED MEMORY?
> +==========================
> +
> +For the purpose of this specification what's meant by "memory" needs to be
> +defined, and the division between CPU and memory needs to be marked out.
> +
> +
> +CACHED INTERACTIONS
> +-------------------
> +
> +As far as cached CPU vs CPU[*] interactions go, "memory" has to include the CPU
> +caches in the system. Although any particular read or write may not actually
> +appear outside of the CPU that issued it (the CPU may may have been able to
> +satisfy it from its own cache), it's still as if the memory access had taken
> +place as far as the other CPUs are concerned since the cache coherency and
> +ejection mechanisms will propegate the effects upon conflict.
> +
Isn't the Alpha's split caches a counter-example of your model,
because the coherency itself is out of order?
Why do you need to include caches and queues in your model? Do
programmers care? Isn't the following sufficient...
: | m |
CPU -----> | e |
: | m |
: | o |
CPU -----> | r |
: | y |
... and bugger the implementation details?
> + [*] Also applies to CPU vs device when accessed through a cache.
> +
> +The system can be considered logically as:
> +
> + <--- CPU ---> : <----------- Memory ----------->
> + :
> + +--------+ +--------+ : +--------+ +-----------+
> + | | | | : | | | | +---------+
> + | CPU | | Memory | : | CPU | | | | |
> + | Core |--->| Access |----->| Cache |<-->| | | |
> + | | | Queue | : | | | |--->| Memory |
> + | | | | : | | | | | |
> + +--------+ +--------+ : +--------+ | | | |
> + : | Cache | +---------+
> + : | Coherency |
> + : | Mechanism | +---------+
> + +--------+ +--------+ : +--------+ | | | |
> + | | | | : | | | | | |
> + | CPU | | Memory | : | CPU | | |--->| Device |
> + | Core |--->| Access |----->| Cache |<-->| | | |
> + | | | Queue | : | | | | | |
> + | | | | : | | | | +---------+
> + +--------+ +--------+ : +--------+ +-----------+
> + :
> + :
> +
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-03-10 5:28 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060315200956.4a9e2cb3.akpm@osdl.org>
2006-03-09 20:29 ` [PATCH] Document Linux's memory barriers [try #4] David Howells
2006-03-09 23:34 ` Paul Mackerras
2006-03-09 23:45 ` Michael Buesch
2006-03-09 23:56 ` Linus Torvalds
2006-03-10 0:07 ` Michael Buesch
2006-03-10 0:48 ` Alan Cox
2006-03-10 0:54 ` Paul Mackerras
2006-03-10 15:19 ` David Howells
2006-03-11 0:01 ` Paul Mackerras
2006-03-10 5:28 ` Nick Piggin [this message]
2006-03-15 11:10 ` David Howells
2006-03-15 11:51 ` Nick Piggin
2006-03-15 13:47 ` David Howells
2006-03-15 23:21 ` Nick Piggin
2006-03-12 17:15 ` Eric W. Biederman
2006-03-14 21:26 ` David Howells
2006-03-14 21:48 ` Paul Mackerras
2006-03-14 23:59 ` David Howells
2006-03-15 0:20 ` Linus Torvalds
2006-03-15 1:19 ` David Howells
2006-03-15 1:47 ` Linus Torvalds
2006-03-15 1:25 ` Nick Piggin
2006-03-15 0:54 ` Paul Mackerras
2006-03-15 14:23 ` [PATCH] Document Linux's memory barriers [try #5] David Howells
2006-03-16 23:17 ` Paul E. McKenney
2006-03-16 23:55 ` Linus Torvalds
2006-03-17 1:29 ` Paul E. McKenney
2006-03-17 5:32 ` Linus Torvalds
2006-03-17 6:23 ` Paul E. McKenney
2006-03-23 18:34 ` David Howells
2006-03-23 19:28 ` Linus Torvalds
2006-03-23 22:26 ` Paul E. McKenney
[not found] ` <21253.1142509812@warthog.cambridge.redhat.com>
[not found] ` <Pine.LNX.4.64.0603160914410.3618@g5.osdl.org>
2006-03-17 1:20 ` Nick Piggin
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=44110E93.8060504@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=alan@redhat.com \
--cc=dhowells@redhat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@ozlabs.org \
--cc=mingo@redhat.com \
--cc=torvalds@osdl.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