The diff did not make it into the tree but it fixed the problem with the cores unscheduling themselves while simulating the parsec benchmarks. However, I was testing this with mesh interconnect + directory coherence, so I did not consider that test good enough to post to the M5 community.
-Rick nathan binkert wrote: > Did this diff ever make it into the tree? Was it correct? > > Nate > > On Wed, May 13, 2009 at 9:06 PM, Rick Strong <[email protected]> wrote: > >> Starring at code and traces, it appears that a fetch attempt occurs >> after waiting for a long latency icache block. The rest of the cpu >> has nothing to do because a jump instruction executed that caused the >> rob to have multiple instructions flushed. The L1 cache unblocks >> because it satisfied an icache request for the cpu for one of the >> squashed instructions. The fetch unit now fetches to new PC of the >> target of >> the last jump instruction. An itbmiss occurs and fetchStatus[tid] == >> TrapPending. Fetch now deactivates itself but the rest of the core's stages >> are deactivated. The trap is never handled. Now I see the note: >> >> "// Send the fault to commit. This thread will not do anything >> // until commit handles the fault. The only other way it can >> // wake up is if a squash comes along and changes the PC. >> " >> >> What happens if commit currently is not an activated stage? Would the >> result be the forever sleeping CPU I see here? The following change >> fixes the problem. Ignore the first diff set as it relates to mesh >> patch. The second part reschedules the Commit Stage that the fault will >> be handled. I hope this helps someone. >> >> --- a/src/cpu/o3/fetch_impl.hh >> +++ b/src/cpu/o3/fetch_impl.hh >> @@ -627,7 +627,7 @@ >> PacketPtr data_pkt = new Packet(mem_req, >> MemCmd::ReadReq, >> Packet::Broadcast); >> data_pkt->dataDynamicArray(new uint8_t[cacheBlkSize]); >> - >> + data_pkt->setSrc(cpu->cpuId()); >> cacheDataPC[tid] = block_PC; >> cacheDataValid[tid] = false; >> >> @@ -1266,6 +1266,7 @@ >> DPRINTF(Fetch, "[tid:%i]: Blocked, need to handle the >> trap.\n",tid); >> >> fetchStatus[tid] = TrapPending; >> + cpu->activateStage(O3CPU::CommitIdx); >> status_change = true; >> >> DPRINTF(Fetch, "[tid:%i]: fault (%s) detected @ PC %08p", >> >> >> Korey Sewell wrote: >> >>> Hi Rick, >>> looks like the activity count went to 0. In the O3, if the activity >>> count is 0 it will sleep the CPU until something wakes it up. >>> >>> I'm thinking that usually what happens is that if the CPU is waiting >>> for a long cache miss, it will just sleep the CPU and then when the >>> cache event completes it will update the activity count. >>> >>> Maybe what's happening is the ITB miss happens, but then it never gets >>> to the code in fetch where the activity count is updated, thus >>> sleeping the CPU indefinitely...??? >>> >>> >>> >> _______________________________________________ >> m5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> >> >> > > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
