Hi Esteban, hi Rich, Your modifications seem to confuse the snoop filter that does sanity checks for the implemented coherence protocol.
I'm not sure about the specifics of your changes but I think a safe way to bypass a cache for a given writeback would be to modify BaseCache::access() https://github.com/gem5/gem5/blob/master/src/mem/cache/base.cc#L1100 . When the BaseCache::access() returns false, the cache forwards the writeback to the memory below. Note that you can't just bypass the cache if the block is already in the cache (one option is to evict it). If you bypass the cache, ignoring an existing block, you're risking breaking the coherence protocol and the snoop filter will panic. I hope this helps. Nikos On 24/09/2019 05:38, Richard Brown wrote: > Hi everyone, > > I am getting similar issues with my implementation. I am getting a panic > error when I bypass a block from private level to main memory, I also > asumed a block is written to public level only from private level > victimizing and does not from main memory filling. > > Any suggestion? Thanks in advance > > Rich > > On Sun, Sep 15, 2019 at 7:00 PM Esteban Badilla <ebadill...@gmail.com > <mailto:ebadill...@gmail.com>> wrote: > > Hello everyone, > > I'm trying to bypass a block from LLC (Last Level Cache, L3 in this > case) to Main Memory with some known conditions. It means, passing > directly from L2 [LP: Last Private Cache] to main memory, a dirty > block is written a clean one is discarded. > > The main purpose is to reduce the amount of writes on the LLC, and > write only blocks that meet a certain condition. If the condition > is not met, the blocks are sent directly to main memory (MM). > > I'm using the gem5 classic memory model, setting up as "mostly > exclusive". I am assuming that the cache memory is filled when > victimizing, that is the blocks when going from main memory to the > cache fill first the L1, when being victimized from L1 they are > written to the L2 and finally to the L3 when they are victimized > from L2. My filter will decide based on a condition is the block is > writting to L3 or bypassed to MM. > > I have modified the cache.cc file specifically the recvTimingReq > function. > > void Cache::recvRDTimingReq(PacketPtr pkt) > { > if (pkt->meetCondition()) { > DPRINTF(LPCache, "Packet %#x meet condition, forwarding it to > L3\n", \ > pkt->getAddr()); > BaseCache::recvTimingReq(pkt); > } else { > assert(!pkt->cmd.isSWPrefetch()); > DPRINTF(LPCache, "Packet %#x has not meet condition, calling > handleTimingReqMiss"\ > ", cmd: %s\n", pkt->getAddr(), pkt->cmd.toString()); > // anything that is merely forwarded pays for the forward > latency and > // the delay provided by the crossbar > > Cycles lat; > CacheBlk *blk = nullptr; > > PacketList writebacks; > // Note that lat is passed by reference here. The function > // access() will set the lat value. > access(pkt, blk, lat, writebacks); > allocateBlock(pkt, writebacks); > // After the evicted blocks are selected, they must be forwarded > // to the write buffer to ensure they logically precede anything > // happening below > doWritebacks(writebacks, clockEdge(lat + forwardLatency)); > } > } > > When I run the simulation I am getting a panic error from the > snoop_filter.cc > > 172251000: system.cpu.l2cache: Sent request to RD for addr 0x422b40 > 172251000: system.cpu.l2cache: Packet 0x422b40 has not meet > condition, calling handleTimingReqMiss, cmd: WritebackDirty > 172505000: system.cpu.l2cache: Sent request to RD for addr 0x422b80 > 172505000: system.cpu.l2cache: Packet 0x422b80 has not meet > condition, calling handleTimingReqMiss, cmd: WritebackDirty > panic: panic condition (sf_item.holder & req_port).none() occurred: > requester > > 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 > is not a holder :( SF value > > 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > Memory Usage: 692524 KBytes > Program aborted at tick 172525500 > > The diagram that shows the system I am simulating is here: > > https://drive.google.com/file/d/1sZfTY4f0djUKwmyv1JDanwzO04wjwAB5/view?usp=sharing > > Thanks in advance for your help. > > -- > Regards, > Esteban Badilla A. > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org <mailto:gem5-users@gem5.org> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > 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 gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
