Hi Biswabandan, I am not worried about the bytes, I am worried about the granularity of the coherency protocol.
Andreas From: biswabandan panda <biswa....@gmail.com<mailto:biswa....@gmail.com>> Reply-To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Date: Monday, 20 April 2015 14:10 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: Re: [gem5-users] Regarding outstanding request queue at coherent_bus.cc Hi Andreas, I am transferring 64 bytes only. The packet contains compressed data. On 20 Apr 2015 18:18, "Andreas Hansson" <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote: Hi Biswabandan, I do not understand the idea of having a single packet for X and X+1. Surely you break the coherency protocol if you do this and suddenly end up with a 128 byte request. To me it sounds like you are creating a next-line prefetcher, but in a very painful way. Am I missing something? Andreas From: biswabandan panda <biswa....@gmail.com<mailto:biswa....@gmail.com>> Reply-To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Date: Sunday, 19 April 2015 05:36 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: [gem5-users] Regarding outstanding request queue at coherent_bus.cc Hi, I am trying an optimization at the memory wherein I service two blocks of cache simultaneously. Suppose say block X is requested by LLC, dram_ctrl.cc now services block X and block X+1, that is I attach both block X and block X+1 to the same packet (pktX) and send it to LLC. A case arises where a request for X+1 is generated by LLC in the meantime (It can be in MSHR and could also have traveled to DRAM read queue). I handle this case through these steps 1. I service that request (X+1) through the packet (pktX) [Only if (X+1) is a read request] 2. Delete the corresponding mshr 3. Also I check at recvTimingResp where if a return packet for Block X+1 comes from DRAM, I simply delete it. I am running into a peculiar case in coherent_bus.cc where the following assert fails for some other totally unrelated block Z "outstandingReq.find(pkt->req) == outstandingReq.end()" This block Z when I trace back, I see is generated for the first time by the LLC, so there is no way that membus would already have block Z request in its outstanding request queue. I am clueless as to how it manifests itself there! Also if I put a check wherein I service block X+1 only if it's corresponding mshr entry is not in service (!mshr->inService for block X+1), I don't run into this problem. Any pointers as to how go about debugging it will be of great help. -- thanks®ards BISWABANDAN http://www.cse.iitm.ac.in/~biswa/<http://www.cse.iitm.ac.in/%7Ebiswa/> “We might fall down, but we will never lay down. We might not be the best, but we will beat the best! We might not be at the top, but we will rise.” -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-users mailing list gem5-users@gem5.org<mailto: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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
