Hi Andreas, I was thinking like a split I-cache access. But I think that is handled differently here.
I will add the condition to check if the state is IcacheWaitRetry() to the isDrained() function in fetch_impl.hh and also change the drain() function in bus.cc. Also please let me know if I need to have special permissions to post to review board? Thanks for the help. Srini On 03/11/14, Andreas Hansson wrote: > Hi Srini, > > I don¹t see the problem you mention with the responses. Why would the > behaviour you describe be erroneous? > > Rather than just increasing the MSHRs, it would be good to fix this issue. > Judging by your first e-mail it sounds like you more or less coded up a > fix already, so I¹d say go ahead and post it on the review board. > > Andreas > > > > On 11/03/2014 02:34, "Srinivasan Narayanamoorthy" <[email protected]> > wrote: > > >Hi Andreas,Thanks for suggesting the solution. > >However, in this case, bus is still not drained. It is still processing > >previous I-cache requests. On a side note, I observed the following. > > > > > >For decent sized fetch widths, we may quickly run out of MSHR's and the > >last fetch may result in a cacheBlock which in-turn sets fetch status to > >IcacheWaitRetry. Now when the first response comes back, the response > >packet may be deleted in processCacheCompletion(PacketPtr pkt). Is this > >expected behavior? > > > > > >Also in my case, I probably only need to increase the number of MSHR's ? > >I see that even the cache hit case gets blocked because of MSHR full. > > > > > >Please let me know how I should proceed here. > > > > > >Srini > > > >On 03/10/14, Andreas Hansson wrote: > >> Hi Srini, > >> > >> I have another suggestion, in the bus drain() we should not only check > >>if > >> the state is IDLE, but also if waitingForPeer != NULL. I think that > >>would > >> fix the problem. In essence the bus would then _not_ be considered > >>drained > >> until the packet gets to retry and succeeds. > >> > >> It might be worth trying. How easy is it for you to reproduce the > >>problem? > >> > >> Andreas > >> > >> On 3/10/14, 10:14 PM, "Srinivasan Narayanamoorthy" > >><[email protected]> > >> wrote: > >> > >> >Hi, > >> > > >> >I did some debugging and figured out whats happening. > >> > > >> > > >> >I cache request fails and fetch enters "IcacheRetryWait" state. (Debug > >> >message : Out of MSHR's) > >> >Now a drain comes along and the CPU starts the drain. > >> >However, while squashing fetch during drain, there is no check if a > >>Retry > >> >packet is pending and hence the memReq is not set to null. > >> >In subsequent drainSanityCheck(), the assert(!memReq) hits. > >> > > >> > > >> >I could think of two solutions to solve this.. > >> >1) check for the IcacheRetryWait state in isDrained() before signalling > >> >drain. > >> >2) clear the memReq while squashing if state is IcacheRetryWait...I am > >> >not sure how to handle recvRetry() though in this case.. > >> > > >> > > >> >I am pretty sure that i might be missing something in either of the two > >> >solutions. I would be very thankful if a solution can be suggested. > >> > > >> > > >> >Thanks > >> >Srini > >> > > >> >On 03/10/14, Srinivasan Narayanamoorthy wrote: > >> >> Hi, > >> >> > >> >> I am trying to switch between two detailed ARM cpu models using > >> >>repeat-switch for bbench. I am hitting the assert(!memReq) assertion > >>in > >> >>drainSanityCheck() after around around 3 seconds (300 switches) of > >> >>simulation time. I looked at the code but could not think of a > >>situation > >> >>where drain would be signalled before a memReq is created. I am going > >>to > >> >>look further but it would be very helpful if some one already has a > >> >>patch/solution to this. > >> >> > >> >> > >> >> My gem5 version is pretty recent from Jan 2014. The cores have DFS > >> >>implemented. I am avoiding other drainSanityCheck() assertions by > >>adding > >> >>a condition to check if the stage is blocked before signalling drain. > >> >> > >> >> > >> >> Thanks > >> >> Srini > >> >> _______________________________________________ > >> >> gem5-users mailing list > >> >> [email protected] > >> >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > >> >_______________________________________________ > >> >gem5-users mailing list > >> >[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. > >> > >> 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 > >> [email protected] > >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > >_______________________________________________ > >gem5-users mailing list > >[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. > > 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 > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
