What can happen is that the a dcache slot can not be released until the memory instruction has completed.
So in your scenario, inst. 1 and inst. 2 make memory operations. Inst. 1 suffers a cache miss and squashes inst. 2. However, inst 2 will not release it's resources (dcache slot) until it completes because if you were to let it go too early then the cache unit's pointers would get compromised once the memory packet from inst. 2 comes back. There's no way to "cancel" a memory request once it gets sent to the memory system. So what you need to do is check the "processCacheCompletion" function. In that function, inst 2's memory operation should eventually come back. Once it comes back, it should see that the inst. 2 is marked as squash and release the dcache slot. On Sun, May 20, 2012 at 3:17 AM, Yuval H. Nacson <[email protected] > wrote: > Thanks for the help.**** > > ** ** > > It turns out I was misreading the debug flags. The cache operation does > respond.**** > > The real problem that I was facing was that there was no available dcache > slots.**** > > I dug in a little and I saw that I had two consecutive load operation. > Both occupy dcache slot on stage 3 and should release it upon completion of > cache access on stage4. However when the first one has a cache miss it > squashed the second and for some reason the dcache slot is not released.** > ** > > I fixed that, but now I found out that the first load doesn't release its > slot either.**** > > ** ** > > I'll dig into that but for now I wanted to let you know that the cache > does work as expected.**** > > ** ** > > Yuval**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Korey Sewell > *Sent:* Tuesday, May 15, 2012 7:55 PM > > *To:* gem5 users mailing list > *Subject:* Re: [gem5-users] Switch on cache miss in SE mode**** > > ** ** > > Unfortunately, > that hasn't been tested in awhile and isnt in the regression tree. I'd > guess one of the recent changes might have provided a bug for the > switch-on-cache miss functionality. > > What you need to do is run gem5 w/trace flags on "InOrderCPUAll,Exec" and > figure out what's the last instruction that is executed for each thread as > well as what instruction is waiting for memory to come back. Maybe you can > turn on just the trace for memory in InOrder (InOrderCacheUnit?) or even > the cache trace (Cache?) and then what you'll see is one instruction going > out and not being acknowledged when it comes back. > > It could be as simple as waking up the CPU with the activity counter on > the cache miss. > > If you start digging into these traces and debugging, we can help you > debug this a bit. It's just a matter of identifying which instruction did > the CPU go to sleep on and that will lead you to the surrounding cause of > it not waking up properly.**** > > On Tue, May 15, 2012 at 12:28 PM, Yuval H. Nacson < > [email protected]> wrote:**** > > Sorry for late response. > > I'm running the in-order model. > > Thanks, > Yuval > > Date: Sun, 13 May 2012 03:31:47 -0400 > From: Korey Sewell <[email protected]> > To: gem5 users mailing list <[email protected]> > Subject: Re: [gem5-users] Switch on cache miss in SE mode > Message-ID: > <CABVets7VC5m6KC2MatgSqMNh=d_q7ve523cvx0wt_fm71j_...@mail.gmail.com > > > Content-Type: text/plain; charset="iso-8859-1"**** > > > what CPU model are you running? > > On Sat, May 12, 2012 at 9:19 AM, Yuval H. Nacson < > [email protected] > > wrote:**** > > > Hello,**** > > > > ** ** > > > > I'm new to gem5.******** > > > > > I'm trying to run 2 threads in ALPHA SE mode. The simulation runs for a* > *** > > > very short while and I get the following message:**** > > > > Exiting @ tick 9223372036854775807 because simulate() limit reached.**** > **** > > > > > Turning on the debug flags I see that on the first data cache miss the > > simulator suspends the active thread and activates the next ready thread. > > When both of my threads are suspended the CPU "goes to sleep" and never* > *** > > > awaken again.******** > > > > > I dug into the code a bit and my guess is that the cache never signals a > > suspended thread that he completed the memory access and the suspended** > ** > > > thread never checks it.**** > > > > ** ****** > > > > > Is there any solution for this problem? Or any suggestion for how should > I**** > > > fix it?**** > > > > ** ** > > > > Thanks,**** > > > > Yuval.******** > > > > > _______________________________________________ > > gem5-users mailing list > > [email protected] > > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > > > -- > - Korey > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users**** > > > > > -- > - Korey**** > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- - Korey
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
