Hi Avais, From the code you just sent, I think what you are trying to do is actually even simpler, essentially you want writebacks to pass through L2 ( without allocating down to the L3 where they allocate. If that’s correct you actually don’t even have to use the tempBlock. In Cache::access() for writebacks bypass the call to allocateBlock assing blk = nullptr and make sure that you return false. That will have the effect you’re looking for.
As for the assertion you’re hitting, I am not entirely sure why it happens. The coherent xbar uses the pkt->req pointer for its routing decisions. For some reason, after handling a request, it didn’t clean up the routeTo map and after some time, when a new packet reuse the same memory and therefore the pkt->req, it finds the old route in the map and crashes. It might be worth making sure that you are on the latest version of gem5. Nikos From: gem5-users <[email protected]> on behalf of Muhammad Avais <[email protected]> Reply-To: gem5 users mailing list <[email protected]> Date: Wednesday, 25 April 2018 at 09:59 To: gem5 users mailing list <[email protected]> Subject: Re: [gem5-users] Write non allocate policy for L2 cache Dear Nikos, Many thanks for your reply. I am trying to implement Write non allocation policy for L2 cache. As suggested by you, I used tempblock to fill in case of writeback miss, still following error appears gem5.opt: build/X86/mem/coherent_xbar.cc:303: bool CoherentXBar::recvTimingReq(PacketPtr, PortID): Assertion `routeTo.find(pkt->req) == routeTo.end()' failed. I made following modification in gem5 if(WR_NON_ALLOC){ //assert(!tempBlock->isValid()); incMissCount(pkt); blk = tempBlock; blk->set = tags->extractSet(pkt->getAddr()); blk->tag = tags->extractTag(pkt->getAddr()); blk->status |= BlkValid; if (pkt->cmd == MemCmd::WritebackDirty) { blk->status |= BlkDirty; } std::memcpy(blk->data, pkt->getConstPtr<uint8_t>(), blkSize); return true; } else{ Allocate as previously } Is still there is some mistake in my implementation? Best Regards, Many thanks, Avais On Tue, Apr 24, 2018 at 8:43 PM, Nikos Nikoleris <[email protected]<mailto:[email protected]>> wrote: Hi Avais, A quick and easy way to achieve this, would be to actually use the tempBlock to fill-in the dcache. The tempBlock will be automatically written back to the L2 as soon as the WriteReq is satisfied. This solution would actually incur a bit of extra traffic between the L1 and L2 but at least it won’t trigger any replacements/evictions in the L1 and it will fill the L2. Alternative solutions would require changes to the way we handle coherence. A needsWritable MSHR that handles WriteReq misses becomes the point of ordering and not filling in the L1 at all would cause problems with ordering. Nikos From: gem5-users <[email protected]<mailto:[email protected]>> on behalf of Muhammad Avais <[email protected]<mailto:[email protected]>> Reply-To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Date: Tuesday, 24 April 2018 at 12:33 To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Subject: [gem5-users] Write non allocate policy for L2 cache Dear all, I want to implement write-non-allocate policy in gem5. Can any one give some hint? In "bool Cache::access(PacketPtr pkt, CacheBlk *&blk, Cycles &lat, PacketList writebacks) " function, inside cache.cc file, where blocks are allocated, i have added following line if(WR_NON_ALLOC{ return false; } but it gives following error gem5.opt: build/X86/mem/coherent_xbar.cc:303: bool CoherentXBar::recvTimingReq(PacketPtr, PortID): Assertion `routeTo.find(pkt->req) == routeTo.end()' failed. Program aborted at tick 56513387376 Can anyone suggest any problem or guide about better solution? Many thanks, Best Regards, Avais IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-users mailing list [email protected]<mailto:[email protected]> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
