Re: [Gems-users] state transitions

["Dave Z." <zhu_dave@xxxxxxxxx>]

Thank you very much. I have another question regarding
a write miss. Let's consider the following scenario -
write miss:

1. I (Line is not found in the cache)
2. IM (Store - write miss: allocate cache block,
allocate TBE, issue GetX, profile the miss, etc.)
3. ISM (Data: write data to cache)
4. MM (All_acks_no_sharers: dirty and locally
modified)
5. MM (Store - write hit)
6. I (Other GetS: send exclusive data to the
requestor)

At the last step, shouldn't we go to O state? I
understand that the data is only locally modified in
MM state, but shouldn't we write it back to the
memory?

The scenario I have in mind is that a processor (P1)
brings a line into the cache on a write miss, modifies
it, and then receives a getS/getX from another
processor (P2). I've thought this scenario would leave
P1 in owned state. Am I missing something? It looks
like the only way to go to owned state is from M, and
to go to M state the only way is from IS state. 

Thank you very much.

Dave

PS. There are three data transitions from IS state:
data, exclusive_data, and shared_data. I understand
exclusive_data and shared_data, but what does "data"
refer to?

--- Greg Byrd <gbyrd@xxxxxxxx> wrote:

> 
> 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.
> >
> >   
> 
> _______________________________________________
> 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.
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com