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
