forked from Imagelibrary/seL4
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:
committed by
Kent McLeod
parent
9f0381c2c2
commit
afbea15710
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user