Re: [Gems-users] About the L2 cache miss profiling

[Dan Gibson <degibson@xxxxxxxx>]

My previous post was unclear. My apologies.

The grand vision behind SLICC was to create a language that was restricted enough to model real hardware (maybe one day translate directly to HDL), but flexible enough to model a variety of coherence protocols without burning out graduate students.

OK, thats fine, but there are some immediate practical concerns to deal with. E.g., SLICC runs on sequential hardware. Moreover, fairly soon after SLICC was finished, a bunch of hacks were added like the one you see below: a dependence in a transition. Sure, it is /possible/ to do this kind of thing in real hardware, but:
- Really those things should be one action
- That 'decrementNumberOfMessagesInt'? There's an extra integer hidden from SLICC -- which means that there is extra STATE which means there are hidden coherence states (yuck!).

So, what I meant to get across in my previous post was that the actions are meant to /model/ 'a bunch of things that happen concurrently', but they are implemented as a bunch of things that happen sequentially (and as you point out, in many cases will NOT work out of that order).

Regards,
Dan

2010/4/9 Ma Dafan <dafan_ma@xxxxxxxxxxx>

"It shouldn't matter in what order the actions are performed"

That means we should try to avoid the potential conflicts in code?

But the order of the first  two actions here may matter, I guess. Am I wrong?
 transition(IFGXX, IntAck) {
    m_decrementNumberOfMessagesInt;
    o_checkForIntCompletion;
    n_popResponseQueue;

  }

2010/4/9, Dan Gibson <degibson@xxxxxxxx>:

In theory, they should be independent. AKA, in the 'simulation model', they happen more-or-less concurrently. It shouldn't "matter" in what order the actions are performed.

In practice, they are performed sequentially.

Regards,
Dan

2010/4/8 Ma Dafan <dafan_ma@xxxxxxxxxxx>

I have another problem: the actions called in transition, are performed sequentially by list order, or just concurrently?

2010/4/9, Ma Dafan <dafan_ma@xxxxxxxxxxx>:

Thx，Dan，I got it.

2010/4/9, Dan Gibson <degibson@xxxxxxxx>:

OLSX, desc="Owned with local sharers, chip is exclusive";
IFLOX, desc="Blocked, forwarded local GETS to local owner but chip is exclusive";

If an L1 issues a GETX to a line in state OLSX, the L2 is owning the line but there are other on-chip caches with a copy of the line (however, there aren't any off-chip copies of the line). However, since the L1 wants an /exclusive/ copy, the GETX cannot be directly serviced by the L2. The state transitions to IFLOX, while invalidations are sent to sharers (except the requestor, of course). The data is present in the L2, so it can be sent to the requestor (i.e., d_sendDataToL1GETX), bu the the requesting L1 does not have the block exclusively until ACKS are received from the other sharers.

In other words, the L2 can supply the data (the GET of the GETX), but not the exclusivity (the X of the GETX), so it is a 'miss'.

Regards,
Dan

On Thu, Apr 8, 2010 at 10:13 AM, Ma Dafan <dafan_ma@xxxxxxxxxxx> wrote:

 Hi, there,
Recently I check in the the file "MOESI_CMP_directory-L2cache.sm" and find something I can not understand.
In the code section cited below, a uu_profileMiss action is called when a L1_getx access actually hit in my opinion.
So I'm confused about the action "uu_profileMiss", can anyone help me?

 transition(OLSX, L1_GETX, IFLOX) {
    i_allocateTBE;
    s_recordGetXL1ID;
    // count number of INVs needed that doesn't include requestor
    h_countLocalSharersExceptRequestor;
    // issue INVs to everyone except requestor
    ee_issueLocalInvExceptL1Requestor;
    d_sendDataToL1GETX
    y_copyCacheStateToDir;
    r_setMRU;
    rr_deallocateL2CacheBlock;
    uu_profileMiss;                                      //why? why miss, is it a hit?
    o_popL1RequestQueue;
  }

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

--
http://www.cs.wisc.edu/~gibson [esc]:wq!

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

--
Regards!
                            Wang

--
Regards!
                            Wang
_______________________________________________
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.

--
http://www.cs.wisc.edu/~gibson [esc]:wq!

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

--
Regards!
                            Wang

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

-- 
http://www.cs.wisc.edu/~gibson [esc]:wq!