> On Sept. 22, 2015, 9:47 a.m., Andreas Sandberg wrote: > > I think this makes sense. There should be no reason to start a quiesce > > operation if the requested delay is 0 ns. > > > > However, I think there is much bigger fish to fry here. If there is a 0 > > cycle quiesce, shouldn't the O3 just CPU suspend and reactivate the thread > > in the same cycle? I had a quick look at FullO3CPU::activateContext() and > > it seems like it refuses to re-activate the CPU if this happens. Unless I'm > > missing something, it seems like this could cause issues with asynchronous > > events. For example, imaging executing a WFI/HLT at the same cycle as an > > interrupt is delivered. The WFI will suspend the CPU and the interrupt > > controller will try to wake it in the same cycle. In the end the wakeup is > > a no-op and we pretty much end up dropping the interrupt.
Thanks for the review. I'm not sure I follow the problem you're describing. The O3 CPU does suspend and reactive in the same cycle. In FullO3CPU::activateContext(), it only avoids activating the context more than once in the same cycle, as guarded by the lastActivatedCycle variable. Is there more that you're worried about there? - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3077/#review7238 ----------------------------------------------------------- On Sept. 1, 2015, 4:15 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3077/ > ----------------------------------------------------------- > > (Updated Sept. 1, 2015, 4:15 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11073:d03187805733 > --------------------------- > sim: Don't quiesce UDelayEvents with 0 latency > > ARM uses UDelayEvents to emulate kernel __*udelay functions and speed up > simulation. UDelayEvents call Pseudoinst::quiesceNs to quiesce the system for > a specified delay. Changeset 10341:0b4d10f53c2d introduced the requirement > that any quiesce process that is started must also be completed by scheduling > an EndQuiesceEvent. This change causes the CPU to hang if an IsQuiesce > instruction is executed, but the corresponding EndQuiesceEvent is not > scheduled. > > Changeset 11058:d0934b57735a introduces a fix for uses of PseudoInst::quiesce* > that would conditionally execute the EndQuiesceEvent. ARM UDelayEvents specify > quiesce period of 0 ns (src/arch/arm/linux/system.cc), so changeset 11058 > causes these events to now execute full quiesce processes, greatly increasing > the total instructions executed in kernel delay loops and slowing simulation. > > This patch updates the UDelayEvent to conditionally execute > PseudoInst::quiesceNs (**an IsQuiesce instruction**) only if the specified > delay is >0 ns. The result is ARM delay loops no longer execute instructions > for quiesce handling, and regression time returns to normal. > > > Diffs > ----- > > src/kern/freebsd/events.cc 6a447a3138ef > src/kern/linux/events.cc 6a447a3138ef > > Diff: http://reviews.gem5.org/r/3077/diff/ > > > Testing > ------- > > > Thanks, > > Joel Hestness > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
