Hi,
Similar to this issue, there is also a confusion (may be i am wrong, please
correct me on this) in the transition:
transition({IS, S_IL0, M_IL0, E_IL0, MM_IL0}, {Inv, Fwd_GETX, Fwd_GETS}) {
z2_stallAndWaitL2Queue;
}
The Inv event with state IS will make the deadlock situation in some of the
parsec benchmarks. The actions for state IS on event: Inv may be like this:
fi_sendInvAck;
l_popL2RequestQueue;
Thanks and Regards,
Sukarn Agarwal
IIT Guwahati
________________________________
From: gem5-users <[email protected]> on behalf of Shirshendu Das
<[email protected]>
Sent: Wednesday, January 30, 2019 1:58:04 PM
To: [email protected]
Subject: [gem5-users] Issue in MESI Three Level Protocol
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 fwd_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
