mcs: Add sporadic flag to SchedControl_Configure

This adds a flags parameter to SchedControl_Configure to enable
configuration of a sporadic SC.

This also allows flags to be added in the future as needed without
breaking the API.

This allows the user to configure an SC either to be constrained as a
sporadic task where accumulated time is only delayed to when a task has
become runnable (implementing the sporadic server algorithm) or
whenever the task becomes the current executing task (implementing the
sliding-window constraint as in constant-bandwidth servers).

This can be used to prevent non-realtime tasks from exceeding bandwidth
under any circumstances, even in an over-committed configuration, whilst
also allowing work-conserving tasks to be configured in the same system.

To implement sporadic servers, we need to ensure that the suspension of
a task cannot be used as a mechanism to amplify budget of a task by
granting that task access to effectively multiple periods worth of
replenishments within a single period.

To align the implementation of SCs with the model of sporadic servers we
must delay available time until the release of a task. Within seL4, a
release would be any time where an SC changes from not being associated
with a Running, RunningVM, or Restart thread to one that is.

This can occur when an SC is bound to a new thread in such a state or
when a thread changes to such a state from any non-running states.

Critically, replenishments should not be delayed at the point when an SC
becomes the current SC (as was the case prior to this commit). This has
the effect of enforcing a continuous, constant bandwidth which is a
restriction that is incompatible with standard scheduling logic.

Accounting for this requires inserting a new refill_unblock_check
call whenever a sporadic SC is unblocked and removing the
refill_unblock_check call from when said SC is scheduled.

Signed-off-by: Curtis Millar <curtis.millar@data61.csiro.au>
This commit is contained in:
Curtis Millar
2020-03-10 15:10:35 +11:00
committed by Kent McLeod
parent 9f0381c2c2
commit afbea15710
13 changed files with 169 additions and 22 deletions

View File

@@ -200,8 +200,15 @@ invoke the appropriate \obj{SchedControl} capability, which provides access to C
on a single node. A scheduling control cap for each node is provided to the initial task at run
time. Threads run on the node that their scheduling context is configured for. Scheduling context
parameters can then be set and updated using
\apifunc{seL4\_SchedControl\_Configure}{schedcontrol_configure}, which allows the budget and period
to be specified.
\apifunc{seL4\_SchedControl\_ConfigureFlags}{schedcontrol_configureflags}, which allows the budget and period
to be specified along with a bitwise OR'd set of the following flags.
\begin{description}
\item[seL4\_SchedContext\_Sporadic]: constrain the execution time only according to the
sporadic server algorithm rather than to a continuous constant bandwidth.
\end{description}
The kernel does not conduct any schedulability tests, as task admission is left to user-level policy
and can be conducted online or offline, statically or dynamically or not at all.