1 / 22

Real Time Linux Operating Systems

Real Time Linux Operating Systems. Swaminathan Sivasubramanian and Sai Sudhir A swami@cs.vu.nl saisud@iastate.edu. Linux as a Real-Time OS. Traditional RT Systems used custom built systems – which were not extensible I.e. tough to develop new applications

adler
Download Presentation

Real Time Linux Operating 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. Real Time Linux Operating Systems Swaminathan Sivasubramanian and Sai Sudhir A swami@cs.vu.nl saisud@iastate.edu

  2. Linux as a Real-Time OS • Traditional RT Systems used custom built systems – which were not extensible I.e. tough to develop new applications • However, as technology improved, generic real-time OS became acceptable • In OS suited for extensible development Linux looks more appealing

  3. Linux (and its Real Time versions) are free!! Linux (and its Real Time versions) are Open Source!! Easy for developing RT applications Why Linux?

  4. Why not Linux? • Linux didn’t have any corporate support until now • Linux, is a very good general purpose operating system, but not so for real-time OS (Why??) • Because, the design motive of a conventional OS and RTOS is different

  5. Linux – A Simplified View

  6. Linux as your real-time solution? • Could increase priority for “real-time” tasks and assume they get scheduled • Problem – Linux optimizes average case whereas an RTOS should work under worst case assumptions

  7. Example Pseudo-code • begin lock process into memory (This will prevent it being out swapped to disk) set the process scheduling policy to high priority do n loops read start time sleep for 100 milliseconds read end time calculate deviation and store result end loop output average and worst-case deviations • end

  8. Example Pseudo-code (contd..) • Measure difference between actual sleep time and expected sleep time • On an idle system it is approx. 100 microseconds • When I/O activity also takes place it now becomes 30 ms • Not suitable for hard RT tasks

  9. Linux – conflicts with RT constraints • Coarse grained synchronization – long intervals when a task has exclusive use of data thereby holding up RT tasks • Linux will batch all operations for efficient use of H/W e.g. frees a set of pages instead of a single page delaying all processes

  10. Linux – conflicts with RT constraints (contd..) • Linux doesn't preempt low-priority task during system call, queues higher priority tasks • Linux reorders requests from multiple processes to make use of H/W efficiently e.g.: to minimize disk-head movement • Linux will make high priority tasks wait for low priority to release resources

  11. Real Time Linux approaches • Modify the current Linux kernel to guarantee RT constraints • Used by KURT • Make the standard Linux kernel run as a task of the real-time kernel • Used by RT-Linux

  12. Modifying Linux kernel • Advantages • Most problems, such as interrupt handling, already solved • Less initial labor • Disadvantages • No guaranteed performance • RT tasks don’t always have precedence over non-RT tasks.

  13. Running Linux as a process of a second RT kernel • Advantages • Can make hard real time guarantees • Easy to implement a new scheduler • Disadvantages • Initial port difficult, must know a tremendous amount about underlying hardware • Running a small real-time executive is not a substitute for a full fledged RTOS

  14. KURT Overview • Developed at University of Kansas • Soft real-time system • Refines the temporal granularity of Linux • Motivation: RT tasks may need a time resolution on the order of microseconds, while non-RT tasks may need a resolution of only milliseconds

  15. KURT Overview (continued) • Result: Timer interrupts are programmed to service earliest scheduled event (results in aperiodic timer interrupts) • Not suitable for hard real-time systems • KURT can’t guarantee priority of RT tasks over non-RT tasks • An RT task can be blocked by a non-RT task (eg: during disk I/O) leading to priority inversion • Suitable for soft RT systems

  16. RT-Linux Overview • Open source Linux project • Supports x86, PowerPC, Alpha • Patch of the regular Linux kernel (simply install the patch and recompile the kernel) • Provides an RT API for developers • Runs Linux kernel as lowest priority process

  17. RT-Linux Task Structure

  18. RT-Linux Interrupt Dispatcher

  19. Linux Modules • Code that can be dynamically linked to the kernel • Modules run in kernel space and hence have access to kernel data structures • Kernel maintains kernel symbol table listing its resources so that loaded modules can use kernel resources • insmod, rmmod, lsmod

  20. RT-Linux Overview (continued) • RT tasks are coded as modules • Modules are inserted and removed at users discretion • Extremely good at handling periodic tasks • Communicates with non-RT kernel and other RT tasks via FIFO queues that are pinned in memory • Tools are provided for graphical analysis of RT execution

  21. Problems with RT-Linux • Currently no support for aperiodic tasks • Not very useful for complex RT systems • Currently limited to simple problems

  22. Important References • RT-Linux : http://www.rtlinux.org

More Related