1 / 20

Supporting Time-sensitive Application on a Commodity OS

Supporting Time-sensitive Application on a Commodity OS. Ashvin Goel, Luca Abeni, Charles Krasic, Jim Snow, Jonathan Walpole. Presented by Wen Sun. Some Slides from “Shuping Tien” (spring 2006) & Madhura S Rama(winter 2006). Overview. Goal Approach Implement TSL

angelahaley
Download Presentation

Supporting Time-sensitive Application on a Commodity OS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Supporting Time-sensitive Application on a Commodity OS Ashvin Goel, Luca Abeni, Charles Krasic, Jim Snow, Jonathan Walpole Presented by Wen Sun Some Slides from “Shuping Tien” (spring 2006) & Madhura S Rama(winter 2006)

  2. Overview • Goal • Approach • Implement TSL • Firm timer • Fine-Grain Kernel Preemptibility • Improved CPU scheduling • Evaluation • Conclusion

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

  4. Approach • Time-sensitiveapplications 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)

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

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

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

  8. Overshoot accuracy vs. overhead tradeoff System call Dispatching timer Poll for timer expiry Kernel Space Overshoot Parameter Time Reprogram timer Time-Sensitive Application require execution Timer Latency

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

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

  11. CPU Scheduling Firm timer uses a combination of • Proportion-Period CPU Scheduling • Priority CPU Scheduling

  12. 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 Proportion-period CPU Scheduling 2/3 Time Proportion Q 1/3 Proportion Q Time Period T

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

  14. Evaluation- Latency in Real Application • Non-kernel CPU load • Kernel CPU load • File System Load

  15. Non-kernel CPU load 0--250 0-40000 -10000--60000

  16. Kernel CPU load 0--400 -10000--90000

  17. File System Load 0--500 -20000--120000

  18. Evaluation- System Overhead • Checking for preemption Three tests (memory access test, folk test, file- system access test) indicate that the overhead is very low • Firm Timers Compare overhead of firm timers in TSL with Standard linux with 20 & 50 timer processes

  19. Evaluation- System Overhead

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

More Related