There are lots of different kinds of events that cause transitions, not
just loads and stores.
The states are listed at the top of the .sm file, and the transitions
are listed at the bottom (along with the actions performed during each
transition). You have to understand the triggers, the transitions, and
the actions to understand the protocol.
Let's the the first part of your scenario -- a read miss.
(1) Because the line is not found in the cache, it is considered in "I"
(idle) state.
(2) The load instruction triggers a "Load" event, which causes a
transition to IS. This is an intermediate state that indicates that
the GETS has been sent, but no reply has been received. The actions
associated with this transition are: allocate cache block, allocate TBE
(a register that keeps track of the outstanding miss), send the GETS to
the home node, profile the miss, get rid of the incoming message that
triggered the Load event.
(3) Under "transitions from IS", we see several possibilities. We could
see a GETS/GETX from some other cache. We could see an Ack from another
cache. The simplest case is that we get the Data response, in which
case we send the requested data to the processor (h_load_hit) and we
transition to SS -- a transitory state that says we've received the
data, but we haven't yet received all the Acks.
(4) While in SS, we count the Acks until we've received them all (which
triggers an "All_acks" or "All_acks_no_sharers" event). Then we
transition to S (and we can deallocate the TBE because the miss is no
longer in progress).
Handling the subsequent write and remote read are left as an exercise
for the reader....
...Greg
PS. Have you looked at the HTML files that are generated by Slicc when
compiling the protocol? There are transition tables for the cache and
the memory (dir) components. That might be simpler than tracing through
the code. Look in gems/ruby/html for your protocol.
Dave Z. wrote:
Hello,
I'm looking into MOESI_SMP_hammer's state transitions
and trying to figure out a transition diagram for
certain conditions as I'm interested in analyzing the
coherence behavior of my benchmarks. But I get
confused a little bit. Let's say that we will bring
data to the cache, modify it, and then another
processor will issue a read request. On an AMD
Opteron, this would be something like: E -> M -> O.
Initially, the cache line will be in exclusive state.
When it's modified, it will be in modified state. On a
read request from another processor, it will be in
owned state. Looking at the state transitions in
MOESI_SMP_hammer, initially the data will be in I
state and a cache block will be allocated. Modifying
the data (GETX) will put it into IM state. But there
is no way out from IM state, in other words, there is
no load/store transition from IM state. So, I'm not
sure if I understand the transitions well. Could
somebody please tell me what I'm missing? Your
comments will be greatly appreciated.
Thank you.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}