sporadic server scheduling in linux theory vs. practice
DESCRIPTION
Sporadic Server Scheduling in Linux Theory vs. Practice. Mark Stanovich Theodore 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. - PowerPoint PPT PresentationTRANSCRIPT
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