If a thread self suspends, it should be marked as ready after resuming.
If a process was already ready when suspended, it should also be
remarked as ready after resuming.
Special care has to be taken in pre-initialization situations so that
processes are put on the right lists, and whether a process is tracked
is already marked as ready.
Change-Id: I15da7d747db591785358d47781297468c5f9fd09
Reviewed-on: https://gem5-review.googlesource.com/c/12445
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Make sure we check for starvation after timed notifications and at the
very end of delta cycles (after delta notifications, not before). Also
reverse the order of starvation checks (whether they apply at all, then
if they're satisfied) to make those checks faster. Checking a bool
is a lot easier than checking if a bunch of other structures are
empty.
Change-Id: I514ff219909823f1f424fde69856d6b510655188
Reviewed-on: https://gem5-review.googlesource.com/12268
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The ready event is what notices that we only wanted to run one delta
cycle, or no delta cycle if there was nothing to do, and return to
sc_main. If the ready event wasn't scheduled, we would advance time
before the ready event ran and returned to sc_main which is incorrect.
Change-Id: Ic3c10a2f1405f744e8c2bd37aa45846ee6e98e12
Reviewed-on: https://gem5-review.googlesource.com/12267
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Methods may need to yield control to other Processes when throwing
them exceptions. In that case, we need to keep track of the fact that
the method doesn't need to be restarted when it resumes within yield.
Change-Id: I829c387d6ddb563b2957db47e55adadbbe6bc51a
Reviewed-on: https://gem5-review.googlesource.com/12265
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This takes advantage of the utility functions that exist a little
better, and also avoids accidentally asymetrically using
eventsToSchedule and eq->(de)schedule.
Change-Id: I1eb1c228d47684cccb9deaf6f3409b77cfbad4cd
Reviewed-on: https://gem5-review.googlesource.com/12260
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
If the readyEvent is still scheduled when sc_main completes, gem5 will
return to it's main fiber and keep executing events, including that
one. That means a delta cycle will run even after sc_main is complete.
This change ensures that the readyEvent has been descheduled as part
of stopping.
Change-Id: I9479ac4ebff3335477b371b02efa6d44c70cbc8e
Reviewed-on: https://gem5-review.googlesource.com/12224
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Make the scheduler clear itself out when it's destructed to ensure that
nobody will try to use it after it's gone away. Also make sure there
are no pending events which might refer to it as well, either systemc
events or gem5 events.
Change-Id: I12dadc06bd9db7016a8dc0c1827b3e630b0d23d5
Reviewed-on: https://gem5-review.googlesource.com/12222
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These events are either scheduled directly, or if no event queue is
yet available they're recorded in a map to schedule later. Since this
was used in a few places (and should have been used for the ready
event), this change moves it into some common functions which remove
some duplication and abstract away this detail.
Change-Id: I4320d7296f4f72344539b2b4b2564a6a27576dd8
Reviewed-on: https://gem5-review.googlesource.com/12219
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Even if the simulation would return from sc_start immediately because
of starvation, this change ensures that sc_start gives control back
to gem5 so that the scheduler will have a chance to set up
sensitivities, etc., before things get torn down.
Change-Id: I39b1fd704fcbe12c299cad9dbd30258e8fe9d032
Reviewed-on: https://gem5-review.googlesource.com/12218
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The initialization phase had been done in a somewhat adhoc way,
partially because delta notifications were being handled as top level
gem5 events which were ordered based on their priorities. This change
makes the initialization phase happen more explicitly, and more in the
order in the spec.
Change-Id: I91d56b63fefcb81c845c52c97826a976a7559fad
Reviewed-on: https://gem5-review.googlesource.com/12217
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Now that delta events are handled explicitly by the scheduler, there's
no reason to run the readyEvent inline when returning from a pause. The
delta events will necessarily be run after the evaluate and update
phases.
Change-Id: Iad6d431a87742354e3a46a0fb44c309aa785ea60
Reviewed-on: https://gem5-review.googlesource.com/12214
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Rather than delegating them entirely to the gem5 event queue and using
priorities to ensure the right thing happens, this change adds a few
new structures which keep track of them and give the scheduler more
control over what happens and in what order. The old scheme was mostly
correct, but there were some competing situations which made it next
to impossible to make everything happen at the right time.
Change-Id: I43f4dd6ddfa488a31073c0318bb41369b1a6117d
Reviewed-on: https://gem5-review.googlesource.com/12213
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Normally delta notifications would be created during the evaluation or
update phases, and so there isn't any problem with them cutting in
front of those stages. When the simulation is paused however, those
notifications could be waiting before the ready event starts and could
preempt it.
This change adds a check for that situation to the end of the pause
event and runs the evalution and update stages inline if necessary.
Change-Id: I4477b2ae8e7980406df00ba7320ae2a24ae2da9b
Reviewed-on: https://gem5-review.googlesource.com/12080
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
That happens when an update is requested before the initialization
phase has started. In that case, the update phase will be manually run
and no event needs to be scheduled, even if that was possible.
Change-Id: I2008e29064d282f82bd1935dbe5b94407aa925b0
Reviewed-on: https://gem5-review.googlesource.com/12078
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
That might happen when a process is being marked as ready at the start
of simulation.
Because the process might not end up on the ready list, displacing it
from the init list, excplicitly pop it off the init list as well.
Change-Id: Iebf972e3e1baedec17b9b99b4da9dd44cd8e6957
Reviewed-on: https://gem5-review.googlesource.com/12047
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Some flags were being updated too early, making the functions think
what they were about to do had already been done. Also, actually check
for and throw the exception installed in a process when it's next
supposed to run, and when injecting an exception schedule that other
process to run immediately.
Change-Id: I0856b69903699b2c66f9dc7f44942bbfe3cfdcc4
Reviewed-on: https://gem5-review.googlesource.com/12046
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This mode implies checking whether there's any activity left either
before starting a delta cycle, or processing delta or timed
notification or timeout.
Change-Id: I0780a1f720cf63f3d2907b8dd28685266b52d6b4
Reviewed-on: https://gem5-review.googlesource.com/12038
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
After sc_start is called, gem5 has run far enough to have an event
queue to schedule the notification events on. Before then, it's still
legal to request a timed notification. The scheduler should keep track
of those requests, and once an event queue is available it should
add them to it.
Change-Id: Ie7445b1f2e616f4bd36044a09dbef9e1d12d7350
Reviewed-on: https://gem5-review.googlesource.com/12036
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This change also gets rid of the SystemC namespace which was
deprecated in favor of sc_gem5.
A few utility functions which check whether certain callbacks have
finished were also implemented. status tracking moved from a global
variable in sc_main.cc to a member of the kernel simobject.
Change-Id: I50967fae9c576fbe45b1faff587aaa824857a289
Reviewed-on: https://gem5-review.googlesource.com/12033
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Track the number of notifications/timeouts that are scheduled at any
given time. This lets us implement sc_pending_activity_at_current_time,
sc_pending_activity_at_future_time, and sc_time_to_pending_activity.
Change-Id: Ia3fcd29bdbfe1a6c77eb52ce4836982d4705263c
Reviewed-on: https://gem5-review.googlesource.com/12032
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This change further modifies the scheduler to implement the sc_pause
and sc_stop functions, and to ensure that calling sc_start again works.
Also, some small changes were made to how processes and contexts are
hooked up. Now, rather than checking whether a process is running to
determine wether it started on its own or needs to be started manually,
there's a bool which explicitly tracks whether it needs this step. The
problem was that once a thread finished, it wasn't considered running
any more. In that case it had run but finished, but that was
indistinguishable from it needing to run but not having been started.
Change-Id: I3aefb5493f91d9efa1a1382586196339b67925fe
Reviewed-on: https://gem5-review.googlesource.com/12031
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This change keeps track of whether a process would have become ready
but was suspended so that it can become ready when the process is
resumed.
Also, this makes a process ignore its static sensitivity while a
dynamic sensitivity is in place.
Change-Id: If3f6c62f370051e574f81bf227746db8c43527e2
Reviewed-on: https://gem5-review.googlesource.com/11715
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This change implements channel updates, and also reworks the scheduler
to delegate more to the gem5 event queue by taking advantage of
event priorities to ensure things happen in the right order. There's
a lengthy comment in scheduler.hh describes how that all works.
Change-Id: I5dee71b86b2e612bb720a4429f3a72e4b7c6d01f
Reviewed-on: https://gem5-review.googlesource.com/11710
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This change implements the "evaluate" part of the delta cycles, and
sketches out a function to run delta cycles and the initialization
phase. The kernel object now schedules an event at time zero which
runs the initialization phase.
Also, some small places which were stubbed out pending a way to check
the currently running process have been filled in now that that's
being tracked.
Change-Id: I6899569eb0195ff1c059fa4e68e90ef162b2f2df
Reviewed-on: https://gem5-review.googlesource.com/11709
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
