Sporadic Server Scheduling in LinuxTheory vs. Practice

Mark StanovichTheodore Baker

Andy Wang

Real-Time Scheduling Theory

• Analysis techniques to design a system to meet timing constraints

• Schedulability analysis– Workload models– Processor models– Scheduling algorithms

Real-Time Scheduling Theory

• Analysis techniques to design a system to meet timing constraints

• Schedulability analysis– Workload models– Processor models– Scheduling algorithms

Periodic Task

timePeriod = T Computation time

WCET = C

Deadline = D

Task

jobs (j1, j2, j3, …)

Release time

Task = {T, C, D}

Periodic Task

sched_setscheduler(SCHED_FIFO)

time

clock_nanosleep()

Periodic Task

• Assumptions– WCET is reliable– Arrivals are periodic

• Not realistic for most tasks

Polling Server

time

time

Job arrivals

Initialbudget

Replenishment period

Polling Server

• Type of aperiodic server• CPU usage no worse than an equivalent

periodic task– Can be modeled as a periodic task

• WCET = Initial Budget• Period = Replenishment Period

• Budget consumed as CPU time is used– CPU time forfeited if not used

• Replenish budget every period

Polling Server

• Good– Bounds CPU usage– Analyzable workload model– Simplicity

• Can be better– Faster response time if budget is not forfeited

Sporadic Server

time

time

Job arrivals

Initialbudget

Replenishment period

replenishments

Sporadic Server

• Originally proposed by Sprunt et. al.• Parameters

– Initial budget– Replenishment period

• Bounds max CPU interference for other tasks• Fits into the periodic task workload model• Better avg. response time than polling server

Sporadic Server

• Scheduling algorithm for fixed-task-priority systems– Can be used in UNIX priority model

• SCHED_SPORADIC is a version of SS defined in POSIX definition– POSIX variant has some errors– Corrected version in another paper

Implementation

• Linux 2.6.38– Sporadic server implementation

• Corrected version– Softirq threading patch ported from earlier RT

patch• Only tested on uniprocessor

Sporadic Server Performance

• Metrics– CPU interference for lower priority tasks– Average response time

An Experiment

Sends UDP packet withcurrent timestamp

Receives UDP packets

Calculate response time based on arrival at UDP layer

Measure CPU time for 10 second burst

A B

Measuring CPU Time

• Regehr's “hourglass” technique– Constantly read time stamp counter– Detect preemptions by large diff in read time– Sum execution chunks

• Hourglass thread lower than net-rx thread• Measures interference from net-rx thread

Measuring CPU Time

• Network receive thread– SCHED_FIFO– Sporadic and polling server

• Budget = 1 msec• Period = 10 msec

• Hourglass thread– SCHED_FIFO– Lower priority than network receive thread

CPU Utilization

Average Response Time

Average Response Time

Interference

• CPU usage not limited properly• Additional overheads

– Context switch time– Cache eviction and reloading

• Not in theoretical workload model• Guarantees of theory require interference to

be included in the analysis

Polling Server

time

timebudget CS+SS 2= aperiodic job CPU time

= aperiodic job arrival

Sporadic Server

time

= aperiodic job CPU time

= aperiodic job arrival

= replenishment period

max_repl2 timebudget CS+SS

Over Provisioning

• All context switch time may not be used– e.g., one replenishment per period

• Better solution– Account for CS time on-line– Charge SS for each preemption

CPU Utilization

Average Response Time

Average Response Time

Can we get the best of both?

Sporadic Sever– Light Load

– Low response time

Polling Sever– Heavy Load

– Low response time– No dropped pkts

Hybrid Server

• How to switch– SS with 1 replenishment is same as polling server– Coalesce replenishments– Ensure bounded interference

• Push replenishments further into the future

• Switching point– Server has work but no budget

Coalescing Replenishments

time

Out of budgetWork available

Coalescing Replenishments

time

Out of budgetWork available

Average Response Time

CPU Utilization

Switching Between Modes

• Immediate coalescing may be too extreme– CPU time could be used for better response time

• Gradual approach– Coalesce fewer replenishments at a time

Gradual Coalescing

time

Out of budgetWork available

Gradual Coalescing

time

Out of budgetWork available

Gradual Coalescing

time

Average Response Time

CPU Utilization

Conclusion

• Theoretical analysis provides solid guarantees• Implementation must match abstract models

– Additional interference terms need to be considered

– SS can fit into the theoretical analysis• CPU interference experienced by both SS and

preempted task

Questions?

42

Differences Break Model

• Budget amplification• Premature replenishment• Incomplete temporal isolation

43

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”

44

Budget Amplification

45

Premature Replenishment

46

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

47

Unreliable Temporal Isolation

SCHED_FIFOSCHED_RR

SCHED_SPORADIC

SCHED_OTHER

Highest Priority

Lowest Priority

Deferrable Server

Deferrable Server Bandwidth Preserving

Allow server to retain budget Periodically replenish budget WCET != Budget

Response Time

Replenishment Policy

replenishment periodreplenishment

initial budget

time

arrival time(work available for server)

Bandwidth Preservation

replenishment

initial budget

time

arrival time(work available for server)

replenishment period

Sporadic Server

time

Analysis Light load

– Sporadic Server• Low response time

– Polling Server• High response time

Heavy load– Sporadic Server

• High response time• Dropped packets

– Polling Server• Low response time• No dropped packets