sim: Don't quiesce UDelayEvents with 0 latency
Review Request #3077 - Created Aug. 28, 2015 and submitted
| Information | |
|---|---|
| Joel Hestness | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
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.
Posted (Aug. 31, 2015, 12:08 a.m.)
Could you add some comments to the code?
Review request changed
Updated (Sept. 1, 2015, 9:15 a.m.)
Description: |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Diff: |
Revision 2 (+14 -2) |
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.