I am taking care of coherency issues. Just go through the last paragraph of my first mail. That might help. On 20 Apr 2015 18:42, "Andreas Hansson" <andreas.hans...@arm.com> wrote:
> 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> > Reply-To: gem5 users mailing list <gem5-users@gem5.org> > Date: Monday, 20 April 2015 14:10 > To: gem5 users mailing list <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> 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 >> > > -- 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
