Hi Andreas, I agree with you. The fundamental problem I meant here is that the UpgradeReq from the bus goes to L2 as a normal timing request and not as a snoop. Thus the cpuside port schedules a retry if the L2 is blocked and does not respond to the request. This I feel is the root cause for the deadlock.
Please correct me if I am wrong. Thanks Srini On 04/23/14, Andreas Hansson wrote: > Hi Srini, > > The message-dependent deadlock that you describe can either be solved by > breaking the cycle (e.g. add an additional port/channel to avoid the > head-of-line blocking) or by restricting the resource usage (wait-hold > relationship), in this case the MSHRs by ³reserving² enough space in > advance. Could you elaborate on why this would not be addressing the > fundamental problem? > > Thanks, > > Andreas > > On 23/04/2014 01:45, "Srinivasan Narayanamoorthy" <narayanam...@wisc.edu> > wrote: > > >Hi Ali, > > > >Thanks for the response. I already did that. That does solve the problem. > >I added a condition to check if the MSHR is "almost full" before issuing > >a prefetch. That way a prefetch can never block the cache. > > > > > >Also I tried to schedule prefetches at a cycle interval than a tick > >interval. That too avoided the deadlock. > > > > > >However,they do not attack the fundamental problem here. > > > > > >Thanks > >Srini > > > >On 04/22/14, Ali Saidi wrote: > >> > >> > >> > >> > >> At first glance I think a solution would be to restrict the number of > >>mshrs that can be used for prefetches to some number that is less than > >>the total number of mshrs in the system. I think that will solve your > >>issue and it sounds like a reasonable approach. > >> > >> > >> > >> Ali > >> > >> > >> > >> On 22.04.2014 12:15, Srinivasan Narayanamoorthy wrote: > >> > >> > > >> > Hi, I am using gem5 ARM with classic memory config and l2 tride > >>prefetcher. There are 4 cores in the system and a shared l2. I think I > >>may have hit a coherence protocol deadlock. Here's whats happening. > >>Cycle 0: Core 2: Schedules an UpgradeReq to be sent out at Cycle 2. > >>Between Cycle 0 and Cycle 2 , there are a lot of L2 prefetch requests > >>which blocks the L2 (they use up all the MSHR's). All prefetches are a > >>hit in Core:2 and it has to respond to the PF_request. Cycle 2, Bus > >>issues snoop request for UpgradeReq(from Core2) to all L1's. However, > >>since l2_cpuside port is not part of the bus slave port list, the > >>request is a normal request at L2 and not a snoop. Because of this (and > >>since L2 is blocked now) the L2 schedules a retry and Core:2 packet > >>queue waits for the retry, which the L2 will send only when it is > >>unblocked. Since Core2: packet queue is the entity that has to unblock > >>L2 by sending the prefetch response, there is a deadlock here(It is > >>waiting for a retry). Whe > > n I tried to limit the prefetch requests such that PF does not block the > >cache at all, there was no deadlock. However, the root of the problem is > >that L2 should respond to the UpgradeReq even when it is blocked just > >like the L1's do. I would be very grateful if a solution is suggested. > >Thanks Srini _______________________________________________ gem5-users > >mailing list gem5-users@gem5.org <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 > > > > > -- 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
