Yes, I've just realized that version 2.1.1 changed the protocol. I'm
working with 2.0.
Anyways, state M is defined as: M, desc="L2 cache entry Modified, not
present in any L1s", format="!b";
So, with the new transition from ISS_MB to M they are allowing M L2
blocks to be present in some L1s.
I guess that in subsequent L1_GETS requests for that block L2 will send
read/write checks to nackers
while in version 2.0 L2 checks for write filters only.
Thanks Nilay,
Ricardo
Nilay Vaish wrote:
I don't know which GEMS distribution you are working with. The one
that I have has the following transition --
// L2 just got the data from memory, but we have Nackers. We can let
nacked block reside in M, but GETS request needs to check read+write
// signatures to avoid atomicity violations.
transition({ISS_MB, IS_SSB}, Unblock_Cancel, M){
//rr_deallocateL2CacheBlock;
// copy NACKers list from unblock message to our sharers list
m_copyNackersIntoSharers;
k_popUnblockQueue;
}
--
Nilay
On Mon, 6 Feb 2012, Ricardo Quislant del Barrio wrote:
NP --> ISS --> ISS_MB --> Depending on event: if "Unblock Cancel"
then --> NP elsif "Exclusive Block" then --> MT.
I think I found the reason:
// L2 just got the data from memory, but we have Nackers. Can't put
it in M or else we might
// violate isolation, since we can allow a transactional read
followed by transactional write when requestor gets it in E state.
transition({ISS_MB, IS_SSB}, Unblock_Cancel, NP){
rr_deallocateL2CacheBlock;
k_popUnblockQueue;
}
Ricardo
Nilay Vaish wrote:
Can point out the how the transitions that you are looking at? It
seems to me that the following transitions will take place --
NP --> ISS --> ISS_MB --> M/MT
--
Nilay
On Mon, 6 Feb 2012, Ricardo Quislant del Barrio wrote:
And what if other L1 has the block in the read set filter only?
Following the L2Cache transition table of
"MESI_CMP_filter_directory" protocol,
"unblock cancel" would be received and the block would be stated as
"NP".
However, it could have been stated as SS if just the write set had
been
checked.
Ricardo.
Nilay Vaish wrote:
That's probably to allow the requestor get exclusive access to the
block if no other L1 has it in the read set either.
--
Nilay
On Fri, 3 Feb 2012, Ricardo Quislant del Barrio wrote:
Hello everybody,
I would like to know why both read and write sets have to be
checked when an L1_GETS request gets the L2 cache
and the block is not present (NP) in there.
The annotation claims that it is for correctness.
Could anybody elaborate on this a bit more?
Why is it not enough to check write filters only?
Thank you very much,
Ricardo
// When L2 doesn't have block, need to send broadcasst to all L1s
to check appropriate filter(s)
transition(NP, L1_GETS, ISS) {
p_profileRequest;
f_profileRequestor;
qq_allocateL2CacheBlock;
ll_clearSharers;
// will mark as exclusive when we get unblocked with success
//nn_addSharer;
i_allocateTBE;
i_setTBEPhysicalAddress;
ss_recordGetSL1ID;
a_issueFetchToMemory;
// for correctness we need to query both read + write filters
*<----*
a_checkL1ReadWriteFiltersExceptRequestor; *<----*
uu_profileMiss;
jj_popL1RequestQueue;
}
--
Ricardo Quislant del Barrio
PhD Student
Dept. Computer Architecture Ph. +34 95 213 7236
University of Malaga Fax. +34 95 213 2790
ETSI Informatica, C. Teatinos e-mail. [email protected]
E-29071 Malaga, Spain
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Ricardo Quislant del Barrio
PhD Student
Dept. Computer Architecture Ph. +34 95 213 7236
University of Malaga Fax. +34 95 213 2790
ETSI Informatica, C. Teatinos e-mail. [email protected]
E-29071 Malaga, Spain
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
