Thank you Sukarn and Fotoushi for your kind response. Dear Fotoushi, yes it is indeed a performance issue but it does not work as per MESI CMP protocol (though no error detects). I am also working to solve this issue. Hopefully, I will complete it by next week. In the meantime, if you complete it then kindly reply to this thread.
Dear Sukarn, I have changed the script according to your advice. Thanks and Regards, Dr. Shirshendu Das Assistant Professor, Department of CSE, Indian Institute of Technology Ropar, Punjab, India http://cse.iitrpr.ac.in/shirshendu/shirshendu.html Ph: 9435277250 On Tue, Feb 12, 2019 at 11:16 AM Pouya Fotouhi <[email protected]> wrote: > Dr. Das, > > I've been recently looking at MESI_Three_Level, and I am trying to fix > some of the issues it currently has. > > The issue you mentioned, is more of a "performance issue" (a significant > one as L0s have zero support for sharing in practice) but does not impact > the correctness of the protocol. > > I'll be submitting a patch to gerrit to fix this issue in the next few > days. Hopefully we'll have it reviewed and added to the public mirror soon. > > Best, > *Pouya Fotouhi* > Graduate Student > Department of Electrical and Computer Engineering > University of Delaware > Newark, DE 19716 > > > On Wed, Jan 30, 2019 at 12:28 AM Shirshendu Das <[email protected]> > wrote: > >> Dear All, >> I was trying to understand the SLICC code for *MESI_Three_Level* >> protocol. During the process, I have found an issue in the protocol. Please >> correct me if I am wrong. >> >> *Caches in three level protocol:* L0 (Private), L1 (Private) and L2 >> (shared). >> *The issue:* The issue is between L1 and L0. When a forwarded GETS >> request arrives at L1 (say L1-x) from any other L1 (say L1-y) via L2, the >> block is evicted from the local L0 (L0-x) before forwarding it to the >> requesting L1 (L1-y). In my understanding, a shared block should not get >> evicted from L0-x before forwarding the block to L1-y under forwarded GETS >> request. >> >> The following code is from *MESI_Three_Level_L1.sm*. In this code, in >> case of *in_msg.Type == **CoherenceRequestType:GETS,* if the block is in >> L0 then *trigger(Event:L0_Invalidate_Else, in_msg.addr,.....)* is called >> to invalidate the block from L0. >> >> in_port(requestNetwork_in, RequestMsg, requestFromL2, rank = 2) { >> .................................. >> if (in_msg.Type == CoherenceRequestType:INV) { >> if (is_valid(cache_entry) && >> inL0Cache(cache_entry.CacheState)) { >> trigger(Event:L0_Invalidate_Else, in_msg.addr, >> cache_entry, tbe); >> } else { >> trigger(Event:Inv, in_msg.addr, cache_entry, tbe); >> } >> } else if (in_msg.Type == CoherenceRequestType:GETX || >> in_msg.Type == CoherenceRequestType:UPGRADE) { >> if (is_valid(cache_entry) && >> inL0Cache(cache_entry.CacheState)) { // If the block is in L0 then remove >> it. >> trigger(Event:L0_Invalidate_Else, in_msg.addr, >> cache_entry, tbe); >> } else { >> trigger(Event:Fwd_GETX, in_msg.addr, cache_entry, tbe); >> //This line is forwarding block directly from L1. >> } >> * } else if (in_msg.Type == CoherenceRequestType:GETS) {* >> if (is_valid(cache_entry) && >> inL0Cache(cache_entry.CacheState)) { *// If the block is in L0 then >> invalidate it.* >> trigger(Event:L0_Invalidate_Else, in_msg.addr, >> cache_entry, tbe); >> } else { >> trigger(Event:Fwd_GETS, in_msg.addr, cache_entry, tbe); >> //This line is forwarding block directly from L1. >> ............................................. >> >> The *MESI_Three_Level_L0.sm* has transitions for f*wd_GETS* and >> *fwd_GETX,* but from my understanding, such transitions will never occur >> in L0 as L1 is not sending appropriate CoherenceRequest to L0. The *Actions >> *written in *MESI_Three_Level_L1.sm *are not forwarding any >> *CoherenceClass:GETS* message to L0. The *Actions* written in L1 ( >> *MESI_Three_Level_L1.sm*) are only sending *CoherenceClass:INV* request >> to L0 (*MESI_Three_Level_L0.sm*). >> >> Thanks and Regards, >> Dr. Shirshendu Das >> Assistant Professor, >> Department of CSE, >> Indian Institute of Technology Ropar, Punjab, India >> http://cse.iitrpr.ac.in/shirshendu/shirshendu.html >> Ph: 9435277250 >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
