#
12334:e0ab29a34764 |
|
30-Nov-2017 |
Gabe Black <gabeblack@google.com> |
misc: Rename misc.(hh|cc) to logging.(hh|cc)
These files aren't a collection of miscellaneous stuff, they're the definition of the Logger interface, and a few utility macros for calling into that interface (panic, warn, etc.).
Change-Id: I84267ac3f45896a83c0ef027f8f19c5e9a5667d1 Reviewed-on: https://gem5-review.googlesource.com/6226 Reviewed-by: Brandon Potter <Brandon.Potter@amd.com> Maintainer: Gabe Black <gabeblack@google.com>
|
#
11937:e6621fafa62d |
|
28-Mar-2017 |
Andreas Sandberg <andreas.sandberg@arm.com> |
sim: Handle cases where Drainable::resume() creates objects
There are cases where Drainable objects need to create new objects in Drainable::resume(). In such cases, the local drain state will be inherited from the DrainManager. We currently set the state to Running as soon as we start resuming the simulator. This means that new objects are created in the Running state rather than the Drained state, which the resume code assumes. Depending on the traversal order in DrainManager::resume(), this sometimes triggers a panic because the object being resumed is in the wrong state.
This change introduces a new drain state, Resuming, that the DrainManager enters as soon as it starts resuming the simulator. Objects that are created while resuming are created in this state. Such objects are then resumed in a subsequent pass over the list of Drainable objects that need to be resumed. Once all objects have been resumed, the simulator enters the Running state.
Change-Id: Ieee8645351ffbdec477e9cd2ff86fc795e459617 Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Reviewed-on: https://gem5-review.googlesource.com/2600 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Weiping Liao <weipingliao@google.com>
|
#
11859:76c36516e0ae |
|
19-Feb-2017 |
Andreas Hansson <andreas.hansson@arm.com> |
sim: Ensure draining is deterministic
The traversal of drainable objects could potentially be non-deterministic when using an unordered set containing object pointers. To ensure that the iteration is deterministic, we switch to a vector. Note that the lookup and traversal of the drainable objects is not performance critical, so the change has no negative consequences.
|
#
11417:6e89c756e1fb |
|
11-Dec-2015 |
Sascha Bischoff <sascha.bischoff@arm.com> |
sim: Add additional debug information when draining
This patch adds some additional information when draining the system which allows the user to debug which SimObject(s) in the system is failing to drain. Only enabled for the builds with tracing enabled and is subject to the Drain debug flag being set at runtime.
|
#
10998:cd22d66592bf |
|
04-Aug-2015 |
Andreas Sandberg <andreas.sandberg@arm.com> |
sim: Initialize Drainable::_drainState to the system's state
It is sometimes desirable to be able to instantiate Drainable objects when the simulator isn't in the Running state. Currently, we always initialize Drainable objects to the Running state. However, this confuses many of the sanity checks in the base class since objects aren't expected to be in the Running state if the system is in the Draining or Drained state.
Instead of always initializing the state variable in Drainable to DrainState::Running, initialize it to the state the DrainManager is in.
Note: This means an object can be created in the Draining/Drained state without first calling drain().
|
#
10913:38dbdeea7f1f |
|
07-Jul-2015 |
Andreas Sandberg <andreas.sandberg@arm.com> |
sim: Refactor and simplify the drain API
The drain() call currently passes around a DrainManager pointer, which is now completely pointless since there is only ever one global DrainManager in the system. It also contains vestiges from the time when SimObjects had to keep track of their child objects that needed draining.
This changeset moves all of the DrainState handling to the Drainable base class and changes the drain() and drainResume() calls to reflect this. Particularly, the drain() call has been updated to take no parameters (the DrainManager argument isn't needed) and return a DrainState instead of an unsigned integer (there is no point returning anything other than 0 or 1 any more). Drainable objects should return either DrainState::Draining (equivalent to returning 1 in the old system) if they need more time to drain or DrainState::Drained (equivalent to returning 0 in the old system) if they are already in a consistent state. Returning DrainState::Running is considered an error.
Drain done signalling is now done through the signalDrainDone() method in the Drainable class instead of using the DrainManager directly. The new call checks if the state of the object is DrainState::Draining before notifying the drain manager. This means that it is safe to call signalDrainDone() without first checking if the simulator has requested draining. The intention here is to reduce the code needed to implement draining in simple objects.
|
#
10912:b99a6662d7c2 |
|
07-Jul-2015 |
Andreas Sandberg <andreas.sandberg@arm.com> |
sim: Decouple draining from the SimObject hierarchy
Draining is currently done by traversing the SimObject graph and calling drain()/drainResume() on the SimObjects. This is not ideal when non-SimObjects (e.g., ports) need draining since this means that SimObjects owning those objects need to be aware of this.
This changeset moves the responsibility for finding objects that need draining from SimObjects and the Python-side of the simulator to the DrainManager. The DrainManager now maintains a set of all objects that need draining. To reduce the overhead in classes owning non-SimObjects that need draining, objects inheriting from Drainable now automatically register with the DrainManager. If such an object is destroyed, it is automatically unregistered. This means that drain() and drainResume() should never be called directly on a Drainable object.
While implementing the new functionality, the DrainManager has now been made thread safe. In practice, this means that it takes a lock whenever it manipulates the set of Drainable objects since SimObjects in different threads may create Drainable objects dynamically. Similarly, the drain counter is now an atomic_uint, which ensures that it is manipulated correctly when objects signal that they are done draining.
A nice side effect of these changes is that it makes the drain state changes stricter, which the simulation scripts can exploit to avoid redundant drains.
|
#
10910:32f3d1c454ec |
|
07-Jul-2015 |
Andreas Sandberg <andreas.sandberg@arm.com> |
sim: Make the drain state a global typed enum
The drain state enum is currently a part of the Drainable interface. The same state machine will be used by the DrainManager to identify the global state of the simulator. Make the drain state a global typed enum to better cater for this usage scenario.
|
#
9342:6fec8f26e56d |
|
02-Nov-2012 |
Andreas Sandberg <Andreas.Sandberg@arm.com> |
sim: Move the draining interface into a separate base class
This patch moves the draining interface from SimObject to a separate class that can be used by any object needing draining. However, objects not visible to the Python code (i.e., objects not deriving from SimObject) still depend on their parents informing them when to drain. This patch also gets rid of the CountedDrainEvent (which isn't really an event) and replaces it with a DrainManager.
|