1
Defects of the POSIX Sporadic Server and How to Correct Them
Mark StanovichTheodore Baker
An-I WangFlorida State University, USA
Michael González HarbourUniversidad de Cantabria, Spain
2
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
3
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.
4
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
5
Replenishment Policy
replenishment period
replenishment
initial budget
time
activation time(work available for server)
6
Bandwidth Preservation
replenishment period
replenishment
initial budget
time
activation time(work available for server)
7
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
8
Differences Break Model
• Budget amplification
• Premature replenishment
• Incomplete temporal isolation
9
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”
10
Budget Amplification
Is this a problem in real systems?
12
Budget Amplification Experiment
• Linux sporadic server implementation– Replenishment period = 10 msec– Budget = 1 msec
• Budget breaks into 2-8 chunks
13
14
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%
120
140
15
16
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
17
18
Premature Replenishment
• Illegal merging of chunks– Violates minimum offset
• Exceeds sliding window
budget constraint
• Single activation time
is oversimplification
19
Premature Replenishment
20
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
21
22
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
23
Solutions
• Maintain all replenishments separately?– Unbounded fragmentation
• Merging chunks essential– Limits fragmentation
• Must not merge illegally– Preserve additional activation times
24
Premature Replenishment
25
26
Lessons Learned
• Transforming a theoretical algorithm into an implementation is not trivial
• Practical considerations– Overruns– Maximum number of replenishments– …
27
Lessons Learned
• Implementation deviation from theoretical model invalidates schedulabilty analysis
• Analysis must be extended to match implementable reality
• Implementation must be analyzable
28
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?
30
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
31
Unreliable Temporal Isolation
SCHED_FIFOSCHED_RR
SCHED_SPORADIC
SCHED_OTHER
Highest Priority
Lowest Priority
32
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
33
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
34
Solution
Highest Priority
Lowest Priority
Idle
No execute
SCHED_OTHER
SC
HE
D_S
PO
RA
DIC
(background priority)SCHED_FIFOSCHED_RR
SCHED_SPORADIC (high priority)
Sprunt Defect
36
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
37
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
38
Polling Server
server budget
T s
time
replenishment
job arrival
Server activations every period (Ts)
ti+1 – ti = Ts
39
Primitive Sporadic Server
server budget
T s
time
replenishment
job arrival
Server activations lower bounded by the period (Ts)
ti+1 – ti ≥ Ts
40
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
41
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)
42
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
43
SCHED_SPORADIC
sched_ss_repl_period
time
replenishments
activationtime
replenishments pending limited to sched_ss_repl_max
Current budget limited to sched_ss_init_budget
sched_ss_init_budget
44
Evaluation
• Linux implementation
• Also, simulator– Allows reduction of “noise” from
implementation
• Demonstrate effects and effectiveness of proposed solutions– Budget amplification– Premature replenishment
45
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