| Author |
Message |
Oliver S.
Guest
|
 Posted:
Thu Feb 24, 2005 7:39 am Post subject:
Two questions regarding Opteron-MESI |
|
|
I've got two questions regarding Opteron's MESI-logic and one regar-
ding the upcoming Horus-chipset.
First question: Does the Opteron issue a broadcast to other CPUs (via
the HT-links) to discover a more recent version of a cache line to be
loaded from its own memory in parallel with speculatively reading that
cacheline or does it first issue that broadcast and then read this CL
from its own memory when this BC didn't discover a more recent version?
Second question: Is it possible to mark a region or inidividual pages
of the memory to be private for a single CPU so that this broadcasts
are prevented? Of course this would make it difficult (but not impos-
sible) to migrate processes and/or threads to other CPUs.
Third question: Does anyone know if the upcoming Horus-chipset will
support duplicate-tags for its managed CPU's caches to shortcut this
broadcasts in the chipset? |
|
| Back to top |
|
 |
Andi Kleen
Guest
|
| Posted:
Thu Feb 24, 2005 7:57 am Post subject:
Re: Two questions regarding Opteron-MESI |
|
|
"Oliver S." <Follow.Me@gmx.net> writes:
| Quote: | I've got two questions regarding Opteron's MESI-logic and one regar-
ding the upcoming Horus-chipset.
First question: Does the Opteron issue a broadcast to other CPUs (via
the HT-links) to discover a more recent version of a cache line to be
loaded from its own memory in parallel with speculatively reading that
cacheline or does it first issue that broadcast and then read this CL
from its own memory when this BC didn't discover a more recent version?
|
That's not how the state machine works. When a CPU changes a cache
line its state is changed first to EXCLUSIVE (this works
asynchronously in respect to the program flow, it won't stall the CPU
on a write). EXCLUSIVE state means that cache line is invalidated in
all other caches.
This means there can be never a "more recent" version of a cache line;
a modified cache line only exists once.
However when it has no cache line in the local cache I believe
it will do an overlapping broadcast yes. At least that is what
the old MPF slides from Fred Weber about the Opteron cache
pipeline suggested.
| Quote: | Second question: Is it possible to mark a region or inidividual pages
of the memory to be private for a single CPU so that this broadcasts
are prevented? Of course this would make it difficult (but not impos-
sible) to migrate processes and/or threads to other CPUs.
|
Sure; just mark it uncacheable using MTRR or PAT. That's commonly
used to improve performance for hardware devices that doesn't support
cache coherency.
The northbridge also has separate registers for remote memory
that tells it which memory range belongs to which CPU; when you
remove memory from there on the remote CPUs they cannot access it.
I don't know if that will actually prevent MOESI transactions
for them though.
-Andi |
|
| Back to top |
|
|
Guest
|
| Posted:
Thu Feb 24, 2005 8:53 pm Post subject:
Re: Two questions regarding Opteron-MESI |
|
|
"Opteron's MESI-logic"
Lets make that MOESI a 5-state cache to cache protocal.
The O state is called Owned and represents the situation where this
processor
has the most up to date data and memory is stale but other processors
can
have read only (S or Shared) access to that line of data.
Mitch |
|
| Back to top |
|
|
Anton Ertl
Guest
|
| Posted:
Thu Feb 24, 2005 9:48 pm Post subject:
Re: Two questions regarding Opteron-MESI |
|
|
MitchAlsup@aol.com writes:
| Quote: | "Opteron's MESI-logic"
Lets make that MOESI a 5-state cache to cache protocal.
The O state is called Owned and represents the situation where this
processor
has the most up to date data and memory is stale but other processors
can
have read only (S or Shared) access to that line of data.
|
Thank you. This is the first time I have seen a definition of the
Owned state that I understood.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html |
|
| Back to top |
|
|
Joe Seigh
Guest
|
| Posted:
Thu Feb 24, 2005 10:54 pm Post subject:
Re: Two questions regarding Opteron-MESI |
|
|
On 24 Feb 2005 07:53:39 -0800, <MitchAlsup@aol.com> wrote:
| Quote: | "Opteron's MESI-logic"
Lets make that MOESI a 5-state cache to cache protocal.
The O state is called Owned and represents the situation where this
processor
has the most up to date data and memory is stale but other processors
can
have read only (S or Shared) access to that line of data.
|
That's little confusing. The cache line being written to would be flickering
between E and O. The shared cache lines would be what, S(stale) vs.
S(current)? I'd leave it at MESI with maybe a new state for shared stale.
There's stuff that can handle stale cache lines but you'd probably want some
new memory barriers to toggle the stale cache lines to invalid state. The
processor could proactively update stale cache back to current shared if
there was spare bus bandwidth.
--
Joe Seigh |
|
| Back to top |
|
|
Del Cecchi
Guest
|
| Posted:
Thu Feb 24, 2005 10:58 pm Post subject:
Re: Two questions regarding Opteron-MESI |
|
|
Joe Seigh wrote:
| Quote: | On 24 Feb 2005 07:53:39 -0800, <MitchAlsup@aol.com> wrote:
"Opteron's MESI-logic"
Lets make that MOESI a 5-state cache to cache protocal.
The O state is called Owned and represents the situation where this
processor
has the most up to date data and memory is stale but other processors
can
have read only (S or Shared) access to that line of data.
That's little confusing. The cache line being written to would be
flickering
between E and O. The shared cache lines would be what, S(stale) vs.
S(current)? I'd leave it at MESI with maybe a new state for shared stale.
There's stuff that can handle stale cache lines but you'd probably want
some
new memory barriers to toggle the stale cache lines to invalid state. The
processor could proactively update stale cache back to current shared if
there was spare bus bandwidth.
|
There are two possible variations for shared data, one in which the
memory has the current data and the other in which the current data
exists only in cache. The latter situation would be if a processor were
to obtain exclusive and do a write. Then another processor does a read
and rather than force the data to flush to main memory, the first
processor supplies the data to the second and transitions from e to o.
At least that is how it seems to me that it ought to work. Data doesn't
go to memory until no processor is using it.
del cecchi |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in