Defects of the POSIX Sporadic Server and How to Correct Them

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 periodreplenishment

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 alwayscharged 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

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

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

18

Premature Replenishment

•

Illegal merging of chunks–

Violates minimum offset

•

Exceeds sliding window budget constraint

•

Single activation timeis oversimplification

19


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

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


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


•

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


•

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

SolutionHighest 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

Ts

time

replenishment

job arrival

Server activations every period (Ts

)

ti+1

– ti

= Ts

39

Primitive Sporadic Server

server budget

Ts

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

Defects of the POSIX Sporadic Server and How to Correct Them

Documents

Transcript of Defects of the POSIX Sporadic Server and How to Correct Them