Defects of the POSIX Sporadic Server and How to Correct Them Mark Stanovich Theodore Baker An-I Wang Florida State University, USA Michael González Harbour Universidad de Cantabria, Spain

Overview POSIX specification broken Budget amplification (accounting error) Interference can grow over time Premature replenishment Invalidates sliding window budget constraint Incomplete temporal isolation No way to limit low priority execution

Motivation Sporadic server (SS) is well known1 Many uses Bounds interference for other tasks Service device drivers Composable systems Only POSIX policy that limits CPU time Alternatives (CBS, TBS, …) Not for fixed-priority systems 1 Sprunt, Sha, and Lehoczky. Aperiodic task scheduling for hard real-time systems.

Sporadic Server Used to service aperiodic jobs in fixed-priority task scheduling Interference like a periodic task Period = replenishment period Execution time = initial budget Average response time < polling server Interference < deferrable server

(work available for server) Replenishment Policy replenishment period replenishment initial budget time activation time (work available for server) 5

Bandwidth Preservation replenishment period replenishment initial budget time activation time (work available for server) 6

SCHED_SPORADIC POSIX variant Differences Conceptually similar to Sprunt SS Differences Allows overruns Max execution ≤ available budget + clock resolution Maximum number of pending replenishments Background priority

Differences Break Model Budget amplification Premature replenishment Incomplete temporal isolation

Budget Amplification Accounting error Overruns not always charged to the server Max execution ≤ server budget + clock res. “if the available execution capacity would become negative...it shall be set to zero”

Budget Amplification 10

Is this a problem in real systems?

Budget Amplification Experiment Linux sporadic server implementation Replenishment period = 10 msec Budget = 1 msec Budget breaks into 2-8 chunks 12

13

How likely is this? Simulate large number of cases Exponential workload distribution Mean job execution time = 10 Various mean interarrival times Server Replenishment period = 120 Budget = 40 Job overruns = 1 time unit Maximum utilization = 34% 14

15

Solutions Just allow negative available capacity? Our solution But overruns can still occur every period Our solution Think of overrun as time received early Charge against future replenishments

17

Premature Replenishment Illegal merging of chunks Violates minimum offset Exceeds sliding window budget constraint Single activation time is oversimplification

Premature Replenishment

Premature Replenishment Simulation Experiment Two tasks Sporadic server Replenishment period = 100 Budget = 42 Higher priority periodic task Period = 141 Execution time specified by x-axis Intuition Longer preemption period can trigger illegal merging of time chunks 20

21

Is this likely? Difficult to demonstrate on random arrivals and execution times Effect does not occur often enough to be measured on a macroscopic scale This anomaly would probably be only a concern in a hard real-time environment 22

Solutions Maintain all replenishments separately? Unbounded fragmentation Merging chunks essential Limits fragmentation Must not merge illegally Preserve additional activation times

Premature Replenishment 15 minute point If running behind cut 17-21

25

Lessons Learned Transforming a theoretical algorithm into an implementation is not trivial Practical considerations Overruns Maximum number of replenishments …

Lessons Learned Implementation deviation from theoretical model invalidates schedulabilty analysis Analysis must be extended to match implementable reality Implementation must be analyzable 27

Conclusion POSIX formulation of SS broken Provided possible corrections Need a standard scheduling policy that enforces time budgets API for SCHED_SPORADIC with correct semantics can serve the purpose

Thank You! Questions?

Defect #3: Incomplete Temporal Isolation With temporal isolation a failure in one task does not prevent others from meeting their timing constraints Problem: Execution at low priority Still preempts non-”real-time” work 30

Unreliable Temporal Isolation Highest Priority SCHED_FIFO SCHED_RR SCHED_SPORADIC SCHED_OTHER Lowest Priority 31

Unreliable Temporal Isolation No upper bound on execution time consumed by SCHED_SPORADIC task Even though SCHED_OTHER tasks are not RT, should allow a mechanism to isolate from overruns of SCHED_SPORADIC threads 32

Unreliable Temporal Isolation Some remedies Background execution of SCHED_SPORADIC Only use idle time Interleave with non-real-time priorities Never execute at background priority Utilize numeric priority to specify functionality 33

Solution Highest Priority SCHED_SPORADIC (background priority) SCHED_FIFO SCHED_RR SCHED_SPORADIC (high priority) SCHED_OTHER Lowest Priority Idle No execute 34

Sprunt Defect

Overview Aperiodic Tasks Arrivals and executions are generally considered random No bound on the CPU runtime Typically scheduled with a server thread to bound CPU consumption and ease analysis

Aperiodic Server Given a budget which it consumes while executing aperiodic jobs Budget is replenished according to the server's rules Typically the server's impact is analyzed by some equivalent periodic task Examples of fixed-priority servers Polling Server Deferrable Server Sporadic Server

Polling Server Ts replenishment server budget time job arrival Server activations every period (Ts) ti+1 – ti = Ts

Primitive Sporadic Server Ts replenishment server budget time job arrival Server activations lower bounded by the period (Ts) ti+1 – ti ≥ Ts

Sporadic Server Parameters Replenishments performed in chunks Execution budget (Cs) Replenishment period (Ts) Server priority Replenishments performed in chunks Used execution time is replenished Ts in the future from the server activation

POSIX Portable Operating System Interface [for uniX] Standard that defines a set of services that an operating system provides to an application Eases portability of applications from one platform to another Widely implemented Linux Mac OS X OpenBSD FreeBSD … Some interfaces are optional (e.g. SCHED_SPORADIC)

Budget Amplification Occurs during overload when all budget is continuously consumed With small enough fragments, a server can achieve an execution capacity arbitrarily close to 100% POSIX only limits the available execution capacity to the initial budget Overruns can happen Control of execution on the processor cannot be assumed to be perfect If overruns do occur, then some fairness mechanism should be used

sched_ss_repl_period SCHED_SPORADIC sched_ss_repl_period replenishments pending limited to sched_ss_repl_max replenishments sched_ss_init_budget time activation time Current budget limited to sched_ss_init_budget

Evaluation Linux implementation Also, simulator Allows reduction of “noise” from implementation Demonstrate effects and effectiveness of proposed solutions Budget amplification Premature replenishment

Effects of Budget Amplification Experiment does not reach 100% CPU utilization due to replenishments overlapping and therefore merged Merging two chunks that exceed the initial budget must be rounded down to the initial budget While there is a bound it still exceeds the load of an equivalent periodic task