Sporadic Server Scheduling in Linux Theory vs. Practice

1. Sporadic Server Scheduling in LinuxTheory vs. Practice Mark Stanovich Theodore Baker Andy Wang

2. Real-Time Scheduling Theory • Analysis techniques to design a system to meet timing constraints • Schedulability analysis • Workload models • Processor models • Scheduling algorithms

3. Real-Time Scheduling Theory • Analysis techniques to design a system to meet timing constraints • Schedulability analysis • Workload models • Processor models • Scheduling algorithms

4. Periodic Task Task = {T, C, D} Task jobs (j1, j2, j3, …) Deadline = D time Computation time WCET = C Period = T Release time

5. Periodic Task sched_setscheduler(SCHED_FIFO) time clock_nanosleep()

6. Periodic Task • Assumptions • WCET is reliable • Arrivals are periodic • Not realistic for most tasks

7. Polling Server Replenishment period time Job arrivals Initial budget time

8. 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

9. Polling Server • Good • Bounds CPU usage • Analyzable workload model • Simplicity • Can be better • Faster response time if budget is not forfeited

10. Sporadic Server Replenishment period time Job arrivals Initial budget time replenishments

11. 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

12. 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

13. Implementation • Linux 2.6.38 • Sporadic server implementation • Corrected version • Softirq threading patch ported from earlier RT patch • Only tested on uniprocessor

14. Sporadic Server Performance • Metrics • CPU interference for lower priority tasks • Average response time

15. An Experiment B A Sends UDP packet with current timestamp Receives UDP packets Calculate response time based on arrival at UDP layer Measure CPU time for 10 second burst

16. 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-rxthread • Measures interference from net-rxthread

17. 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

18. CPU Utilization

19. Average Response Time

20. Average Response Time

21. 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

22. time Polling Server = aperiodic job arrival = aperiodic job CPU time

23. time Sporadic Server = aperiodic job arrival = replenishment period = aperiodic job CPU time

24. 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

25. CPU Utilization

26. Average Response Time

27. Average Response Time

28. Can we get the best of both? • Sporadic Sever • Light Load • Low response time • Polling Sever • Heavy Load • Low response time • No dropped pkts

29. 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

30. time Coalescing Replenishments Out of budget Work available

31. time Coalescing Replenishments Out of budget Work available

32. Average Response Time

33. CPU Utilization

34. 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

35. time Gradual Coalescing Out of budget Work available

36. time Gradual Coalescing Out of budget Work available

37. time Gradual Coalescing

38. Average Response Time

39. CPU Utilization

40. 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

41. 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 46

47. Unreliable Temporal Isolation Highest Priority SCHED_FIFO SCHED_RR SCHED_SPORADIC SCHED_OTHER Lowest Priority 47

48. Deferrable Server

49. Deferrable Server • Bandwidth Preserving • Allow server to retain budget • Periodically replenish budget • WCET != Budget

50. Response Time