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> 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> > Reply-To: gem5 users mailing list <gem5-users@gem5.org> > Date: Sunday, 19 April 2015 05:36 > To: gem5 users mailing list <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/ > > “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 > 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
