Hi all and maintainer,,
I have some confusion and a possible bug report about prefetcher. The
report is in the second half of the following description.
Confusion:
I noticed that there is a comment when the prefetcher->notify is call. It
is in the "Cache::recvTimingReq" and says:
"*// We should call the prefetcher reguardless if the request is*
*// satisfied or not, reguardless if the request is in the MSHR or*
*// not. The request could be a ReadReq hit, but still not*
*// satisfied (potentially because of a prior write to the same*
*// cache line. So, even when not satisfied, tehre is an MSHR*
*// already allocated for this, we need to let the prefetcher know*
*// about the request*
if (prefetcher) {
// Don't notify on SWPrefetch
if (!pkt->cmd.isSWPrefetch())
next_pf_time = prefetcher->notify(pkt);
}
"
I'm a little confused with these.
As far as I know, if we configure that a prefetch request should issued
when a cache miss occurs, we should call the prefetcher ONLY when the
request is not satisfied and this request is not in MSHR, right? If
satisfied, the cache will fetch the right data. If the request is already
in MSHR, it can come from the previous outstanding demand request or
prefetch request which are still in service, so we shouldn't call the
prefetcher. So here I really don't understand this statement: "* reguardless
if the request is*
*// satisfied or not, reguardless if the request is in the MSHR or*
*// not."*
In addition, about "*because of a prior write to the same **cache line.", *it
looks like a RAW for the same data, and the previous write has not
finished, so the subsequent read (that is, current read request) can't
continue and can't be satisfied. That means that previous write request
encountered a miss but hasn't allocated its new data line. However, the
comment mentions that current request could be a ReadReq hit (it means
ReadReq found this line). See, it is a contradiction.
Also about "*we need to let the prefetcher know **about the request"*, does
that mean "we need to let the prefetcher check whether the request is in
the MSHR or not"?
A possible bug:
Please see the following code (in Cache::recvTimignReq):
*" allocateMissBuffer(pkt, forward_time, true);*
* }*
* if (prefetcher) {*
* // Don't notify on SWPrefetch*
* if (!pkt->cmd.isSWPrefetch())*
* next_pf_time = prefetcher->notify(pkt);*
* }*
* }*
*"*
if pkt's request was allocated an entry in *allocateMissBuffer, *it should
be found in the following prefetcher->notify() in which
Cache::inMissQueue() is called. However, when I debug this code, I found it
is not the case. The notify() can't detect the just inserted MSHR entry.
After reading lots of code, I found its reason.
The allocateMissBuffer(...)'s implementation is:
-------------------------------------------------------------------------------
MSHR *allocateMissBuffer(PacketPtr pkt, Tick time, bool requestBus)
{
return allocateBufferInternal(&mshrQueue,
*blockAlign(pkt->getAddr())*, blkSize,
pkt, time, requestBus);
}
---------------------------------------------------------------------------------------
It use the addr "*blockAlign(pkt->getAddr())" *when inserting a request
packet request.
But in the call chain "prefetcher->nofity() ==> observeAccess() ==>
inMissQueue() ==>Cache->insMissQueue()",
----------------------------------------------------------------------------------------
the Cache::inMissQueue()'s implementation is:
bool inMissQueue(Addr *addr*, bool is_secure) const {
return (mshrQueue.findMatch(addr, is_secure) != 0);
}
---------------------------------------------------------------------------------------------
See, the inMissQueue uses *addr* (that is, pkt->getAddr()) rather than
*blockAlign(addr)*. The key point is here. After I add the blockAlign, the
notify can detect the just inserted MSHR entry.
The version I use is: gem5-stable-629fe6e6c781.tar.bz2
I'm not sure if this is a bug. So please verify it. Thank you.
gjins
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
