1 / 30

Key Requirements and Challenges in Real-Time Operating Systems for Cyber-Physical Systems

This presentation discusses the essential requirements of real-time operating systems (RTOS) in cyber-physical systems, focusing on predictability, user configurability, and reliability. It highlights traditional OS design issues, particularly for multicore platforms, and introduces LITMUS, a testbed for multiprocessor scheduling in real-time systems. Key implementation issues such as scheduling algorithms, interrupts, priority inversions, and resource sharing strategies are examined, alongside empirical results from various platforms, including Niagara and Intel Xeon, to illustrate performance and overheads in real-time scheduling.

trista
Télécharger la présentation

Key Requirements and Challenges in Real-Time Operating Systems for Cyber-Physical Systems

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. ECE 720T5 Fall 2012 Cyber-Physical Systems Rodolfo Pellizzoni

  2. Topic Today: OS • Key traditional requirements of Real-Time OS: • OS Predictability • User Configurability • Reliability • Additional requirement – OS should efficiently support the underlying HW platform. • Especially important for multicore! • Unfortunately, traditional OS design is far from predictable…

  3. LITMUS

  4. LITMUS • Linux Testbed for Multiprocessor Scheduling in Real-Time • Essentially, a soft-real time multiprocessor tested • Implements a variety of different scheduling algorithm and synchronization mechanisms • Many papers for different platforms…

  5. Implementation Issues… • Scheduling plug-ins • Locks and Run-Queues • Migration and race conditions • Timers implementation • Quantum implementation • Run queue implementation • Debugging

  6. Other Common Issues • Interrupts • In Linux, typically divided in top and bottom handler • Top (ISR): creates unpredictable interference • Bottom (kernel thread): must be properly scheduled • Priority Inversions in the Kernel • Virtual Memory • Paging has no concept of task priority • Global replacement decisions do not guarantee isolation • I/O Scheduling • Similar to virtual memory, except the OS often has less control

  7. Refresh: Multiprocessor Scheduling

  8. Measured Overheads: Niagara

  9. Results: Niagara, HR light tasks

  10. Results: Niagara, HR medium tasks

  11. Results: Niagara, HR heavy tasks

  12. Results: Niagara, SR light tasks

  13. Results: Niagara, SR medium tasks

  14. Results: Niagara, SR heavy tasks

  15. Other Platforms… • An Empirical Comparison of Global, Partitioned, and Clustered Multiprocessor EDF Schedulers • Intel Xeon, 8 sockets, 6 cores per socket (total 24 cores). • LVL2 shared among 2 cores, LVL3 shared among 6 cores. • Abandoned P-fair… • Weighted schedulability: • D: cache-induced delay • S(U,D): percentage schedulable task sets for utilization U and cache delay D

  16. Cache-Induced Delay, Intel

  17. Results: Intel, SR light tasks

  18. Results: Intel, SR medium tasks

  19. Results: Intel, SR heavy tasks

  20. Resource Sharing In Multicore • Real-Time Synchronization on Multiprocessor: To Block or Not to Block, to Suspend or Spin? • General solution adopted by the authors: • If resource is shared only by tasks within the same run-queue, use priority inheritance (GEDF) or SRP (PEDF) • If resource is shared among tasks in multiple run-queues, simply run the task non-preemptively.

  21. Alternative? • Spin-lock • Busy-waiting until you get the resource; supports FIFO ordering to prevent starvation • Lock-free • Try to perform an operation on the object; if it fails, retry until success. • If multiple tasks try at the same time, at least one will succeed. • Wait-free • No retry, every task succeeds after fixed number of instructions (can be large). • Lock and wait-free: very dependent on data structure

  22. Spinning is better than suspending…

  23. … unless you care about background computation

  24. Interrupt Management

  25. Accounting for Interrupts • An overview of interrupt accounting techniques for multiprocessor real-time systems • What to get out of the paper: • Types of interrupts • Maskable/ Non-maskable • Split interrupt handling • Dedicated interrupt core, timer multiplexing • … and the three ways to account (quantum, task and core-based).

  26. Results: Niagara, HR light tasks

  27. Results: Niagara, HR light tasks

  28. Results: Niagara, SR light tasks

  29. Interrupt Management – Device Interrupts • What to do with Device Interrupts? • Fundamental tradeoffs: • Serve the device as soon as possible – high interference on real-time tasks. • Do not serve the device – high latency/data lost. • Interrupt coalescing (ex: network cards) • Buffer large amount of data on device (input) or main memory (output) • Send an interrupt only after buffers are full (input) / empty (output)

  30. Interrupt Accounting – Device Interrupts • Bottom-half can be scheduled as an aperiodic task. • Top-half solutions: • Allow all ISR, bound interference (i.e., dbf) • Regulate in hw. • Regulate in sw – use a non-preemptive aperiodic server. • Ex: Non-preemptive interrupt scheduling for safe reuse of legacy drivers in real-time systems Us 1-Us

More Related