Defects of the POSIX Sporadic Server and How

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 1

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 2

Motivation • Sporadic server (SS) is well known 1 • 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. 3

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 4

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

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

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

Differences Break Model • Budget amplification • Premature replenishment • Incomplete temporal isolation 8

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” 9

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? – But overruns can still occur every period • Our solution – Think of overrun as time received early – Charge against future replenishments 16

17

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

Premature Replenishment 19

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 23

Premature Replenishment 24

25

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

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 28

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 SCHED_FIFO SCHED_RR SCHED_SPORADIC (high priority) SCHED_OTHER Lowest Priority Idle No execute SCHED_SPORADIC (background priority) Highest Priority 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 36

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 37

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

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

Sporadic Server • Parameters – 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 40

POSIX • Portable Operating System Interface [for uni. X] • 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 Open. BSD Free. BSD … • Some interfaces are optional (e. g. SCHED_SPORADIC) 41

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 42

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

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

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 45