170 likes | 256 Views
Supporting Time-sensitive Application on a Commodity OS. By Ashvin Goel, Luca Abeni, Charles Krasic, Jim Snow, Jonathan Walpole Presenter: Shuping Tien. Overview. Motivation Goal Approach Implement TSL Firm timer Fine-Grain Kernel Preemptibility Improved CPU scheduling Evaluation
E N D
Supporting Time-sensitive Application on a Commodity OS By Ashvin Goel, Luca Abeni, Charles Krasic, Jim Snow, Jonathan Walpole Presenter: Shuping Tien
Overview • Motivation • Goal • Approach • Implement TSL • Firm timer • Fine-Grain Kernel Preemptibility • Improved CPU scheduling • Evaluation • Conclusion
Motivation • Increasing use of time-sensitive application on general-purpose OS • Most commodity OS targeting to have max system throughput, or only focusing on hard real-time application performance • System throughput decreases
Goal • Satisfying time-sensitive application time constraint • Attempt to integrate support for time-sensitive applications without sacrificing performance of traditional throughput-oriented applications • Build Time-Sensitive Linux (TSL) • While support time-sensitive application, not degrade throughput-oriented application
Approach • Time-sensitive applications require • Timely resources allocation • Low kernel latency : Timer latency + preemption latency + scheduling latency Preemption Latency Timer Latency Scheduling Latency Time Interrupt Handler Another app Scheduled Wall-clock time event Timer Interrupt Scheduler Application Scheduled (Activation)
Approach • Improve the three keys causing latency • Accurate timing mechanism • Firm timer • Responsive kernel • Lock-breaking preemptible kernel • Effective CPU scheduling algorithm • Proportion-period scheduler • Priority-based scheduler
Timer Mechanism • Periodic Timers • Periodic timer interrupts. Max timer latency equals to the period. • Reducing latency increases interrupt overhead • One-Shot (Hard) Timers • Interrupts only when needed • Cost of timer reprogramming, fielding interrupts • Soft Timers • Reduce cost of context switch caused by interrupts • Cost of polling, timer latency • Firm Timers • Combines all the advantages of these timers above • Incurs very low overhead
Firm Timer design • Providing accurate timing mechanism with low overhead • Combining one-shot timers with soft timers by exposing a timer overshoot parameter bounding the latency. • Programming one-shot timer to fire after an overshoot amount of time after the next timer expiry • If a system call occurs after a timer has expired but before one-shot timer generate interrupt when soft timer is effective. • Reprogramming one-shot timer for the next timer expiry – not incur overhead
Overshoot accuracy vs. overhead tradeoff System call Poll for timer expiry Dispatching timer Kernel Space Overshoot Parameter Time Time-Sensitive Application require execution Reprogram timer Timer Latency
Firm Timer Implementation • Maintains a timer queue for each processor • One-shot APIC timer is programmed to generate an interrupt at the next timer expiry event and global overshoot value (can be made dynamic) • Soft timers enabled using non-zero timer overshoot value • Periodic timer used when a timer needs longer timeout due to more efficient data structure • TSL use the standard POSIX interface calls - modified the implementation to use firm timers
Fine-grained kernel preemptibility • Problem: • Larger size of non-preemptible secion results in greater kernel latency • Approaches: • Explicit insertion of preemption points • Allow preemption anytime the kernel is not accessing shared data structures • Robert Love’s lock-breaking preemptible kernel
CPU Scheduling Firm timer uses a combination of • Proportion-Period CPU Scheduling • Priority CPU Scheduling
Proportion-period CPU Scheduling • Provides “temporal protection” by allocating each task a fixed proportion of the CPU at each task period • Adjustable Q and T by using a feedback controller mechanism • Improves accuracy of scheduling analysis 2/3 T1 Time Proportion Q 1/3 T2 Proportion Q Time Period T
Priority-based CPU Scheduling • Real-time priorities assigned based on application needs • TSL schedules fixed priority tasks in the background • Exception: Shared server tasks -> Priority Inversion • Use highest locking priority protocol (HLP) to cope with priority inversion • Minimizes scheduling latency
Evaluation- Latency in Real Application • Kernel CPU load
Evaluation- System Overhead • Cost of executing firm timers
Conclusion • TSL can support applications requiring fine-grained resource allocation and low latency • TSL provides effective supports to both time-sensitive and throughput-oriented applications as a general purpose operating system