----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3077/#review7238 -----------------------------------------------------------
Ship it! 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. - Andreas Sandberg On Sept. 1, 2015, 5: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, 5: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
