Hi Malek,
I think the term blocking is confusing because it's really an overloaded
term. There's a distinction is between blocking CPUs and blocking memory
systems, and they are distinct.
As you say below, a TimingCPU is a blocking CPU and only has one outstanding
instruction going at a time. However, since GEMS is a coherence modeling
infrastructure, obviously you take best advantage of it by running a CMP
simulation or a multisocket simulation, where there are multiple CPUs. A
blocking *protocol* is a protocol that essentially blocks on actions to an
address that is in a transient state, e.g. in the process of writing back
and not in a stable state like M/O/E/S/I. So, you could have a blocking
protocol with a non-blocking CPU, for example, because they are talking
about blocking totally different things (insts vs. addresses), e.g. the CPU
has multiple memory operations outstanding, all being satisfied by the
memory system, but once two CPUs try to do things to a *single* address that
are in conflict, then operations on that address across the system become
serialized. Even if you have blocking CPUs and a blocking protocol, you can
still have multiple requests (up to N for N CPUs) flowing through Ruby, and
the protocol will not block unless there is an issue with two of the CPUs
accessing the same address in a conflicting way.
I hope that helps and makes sense.
Lisa
On Mon, Mar 21, 2011 at 1:21 PM, Malek Musleh malek.mus...@gmail.comwrote:
Hi,
1) I was wondering if the MESI_CMP protocol is currently implemented
as a 'blocking' protocol, similar to how the MOESI_CMP version is.
I see that on this link on the GEMS page that it indicates that the
MOESI_CMP one is blocking, but doesn't indicate anything about the
MESI_CMP version.
http://www.cs.wisc.edu/gems/doc/gems-wiki/moin.cgi/Protocols?action=fullsearchcontext=180value=blockingtitlesearch=Titles
In the MOESI_CMP Version there are coherenceResponseType Messages such
as 'Unblock' / 'Exclusive_Unblock' which seems to enforce the blocking
aspect, and I also see these types in the MESI version, but just
implementing them does not necessarily enforce blocking in all
possible situations.
2) Even if the MESI version is non-blocking, because Ruby only
currently works with the Timing CPU Model, only one request can be
issued to the memory model at a time anyway (and I believe the CPU
stalls anyway until that request COMPLETES), but generally is it
possible to have multiple outstanding/in progress in the ruby memory
model even though Timing CPU is Blocking?
For example, can Core 0 do a STORE X to L1 as L1 does a writeback of
Data: Y to L2?
I suspect no, that in a blocking Cache Coherence Protocol I cannot do
that, but just wanted to confirm.
Malek
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
