Hi Nilay,
Thanks for your reply. I tried deleting the MSHR allocated for the prefetch
request in case of a write back to the same address. I tried running the
benchmark again for which I was observing this assertion failure, and with
this patch, that condition is not asserted as of now. But can you point out
if the code can give break some other condition or is not doing the right
thing or should be included in some other function?
Following is the patch for the cache/cache_impl.hh file.
$ diff cache_impl.hh cache_impl_prefetch.hh
392a393,416
>
> //Trying to fix prefetch issue
> if(prefetcher) {
> Addr temp_blk_addr = blockAlign(pkt->getAddr());
> DPRINTF(Prefetch_Issue,"In access::writeback case,
temp_blk_addr = %#x\n",temp_blk_addr);
> MSHR *temp_mshr = mshrQueue.findMatch(temp_blk_addr);
>
> if (temp_mshr && !(temp_mshr->inService)) {
> if(temp_mshr->hasTargets())
> {
> PacketPtr temp_tgt_pkt = temp_mshr->getTarget()->pkt;
> if(temp_tgt_pkt->cmd == MemCmd::HardPFReq) {
> DPRINTF(Prefetch_Issue,"A prior prefetched req to
block addr %#x exists\n", temp_mshr->addr);
> temp_mshr->popTarget();
> if(!temp_mshr->hasTargets()) {
> MSHRQueue* temp_mq = temp_mshr->queue;
> temp_mq->deallocate(temp_mshr);
> }
> }
> }
> }
> }
> //Trying to fix prefetch issue
Thanks,
Reena
On Tue, Jun 7, 2011 at 4:10 PM, Nilay Vaish <ni...@cs.wisc.edu> wrote:
> On Tue, 7 Jun 2011, reena panda wrote:
>
> Can somebody help out with this?
>>
>> On Mon, Jun 6, 2011 at 3:17 PM, reena panda <reena.pa...@gmail.com>
>> wrote:
>>
>> Hi,
>>>
>>> I am using m5's Inorder cpu model and ALPHA in the SE mode. I am running
>>> the SPEC2k6 benchmarks and am running into an issue when turning on the
>>> prefetcher for l2cache.
>>>
>>> m5.opt: build/ALPHA_SE/mem/cache/cache_impl.hh:803: Packet*
>>> Cache<TagStore>::getBusPacket(Packet*, typename TagStore::BlkType*, bool)
>>> [with TagStore = LRU]: Assertion `needsExclusive && !blk->isWritable()'
>>> failed.
>>> Program aborted at cycle 25061282500
>>>
>>> I tried to debug the issue. The issue is coming up in the following
>>> scenario:-
>>>
>>> In the l2 cache,
>>> a) A check is performed in the getNextMSHR function, when a prefetch
>>> request is popped off the prefetch queue to check if the block is already
>>> resident in the cache. In my case, this check says that the block is not
>>> resident in the l2cache and hence an MSHR gets allocated for it.
>>>
>>> b) But in the mean time, a writeback is initiated in the dcache for the
>>> same address. I believe a writeback gets immediately propagated to the
>>> l2cache. So, now a block for that address gets allocated in the L2cache
>>>
>>> c) By the time, this original prefetch request's MSHR is acted upon, the
>>> block becomes resident in the l2 cache(coz of 2 above) , which causes the
>>> above assertion failure as prefetch requests are not exclusive requests.
>>>
>>> I am not sure, but there might be more such corner cases(which I havent
>>> come across) which might cause the issue too. I found posts similar to
>>> this
>>> earlier in the m5 archives, but havent found a solution. Has anybody come
>>> up
>>> with a work around for the issue yet?
>>>
>>> Thanks,
>>> Reena
>>>
>>>
>>
> Can you not cancel the prefetch request in case of write back? This is just
> my suggestion, I don't know what happens in an actual processor.
>
> --
> Nilay
> _______________________________________________
> gem5-users mailing list
> gem5-users@m5sim.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
gem5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
