RT Linux

1. RT Linux An approach to hard real-time

2. What is Real-Time (RT) • System that has to perform its functions by responding to synchronous or asynchronous events within a specified amount of time. • May be • Soft RT – occasionally allowed to miss deadlines (eg. Updating a video display) • Hard RT – Meeting the deadline is absolutely critical (eg. Rocket controller)

3. Incompatibility with Timesharing Systems • Timesharing systems try to optimize average case but RT systems must consider worst case. • Contradictory design goals for the two – what is good for the average case tends to deteriorate the worst case. A classic example is virtual memory and demand paging.

4. Unsuitability of Linux for Hard RT • Unpredictable scheduling – depends on system load. • Coarse timer resolution (10 ms) • Non-preemptible kernel • Disabling of interrupts used for coarse grained synchronization. • Use of virtual memory • Reordering of requests for efficiency (e.g. for disk I/O )

5. POSIX 1003.1b Standard • For soft RT features in UNIX • It requires the following • Preemptive priority scheduling • Locking of virtual pages into memory • Real-time signals • Improved IPC • Improved timers • Linux only partially conforms to the above. (mlock and setsched system calls)

6. RT Linux - Aims • Achieve hard RT performance. • High level of timer precision in scheduling. • To provide low interrupt latency. • Customized scheduling. • Minimal changes to the Linux kernel so that the full range of OS services are available.

7. RT Linux - Approach • Inspired by MERT (Bell Labs 1978) – a full-fledged Virtual Machine (VM) concept. • RT Linux uses VM concept limited to interrupt emulation. • It slips a small, simple, RT OS underneath Linux. • Linux becomes an idle task for this OS.

8. RT Linux – Approach (Contd.) • A layer of emulation software between Linux kernel and interrupt controller hardware. • Prevents disabling of interrupts by Linux. • cli, sti and iret are replaced by corresponding soft (emulated) versions.

9. Interrupt Emulation • S_CLI : movl $0, SFIF • S_STI : sti pushfl pushl $KERNEL_CS pushl $1f S_IRET 1:

10. Interrupt Emulation (Contd.) • S_IRET: push %ds pushl %eax pushl %edx movl $KERNEL_DS, %edx mov %dx, %ds

11. Interrupt Emulation (Contd.) cli movl SFREQ, %edx andl SFMASK, %edx bsfl %edx, %eax jz 1f S_CLI sti jmp SFIDT (,%eax,4)

12. Interrupt Emulation (Contd.) 1: movl $1, SFIF popl %edx popl %eax popl %ds iret

13. RT Linux – Tasks • Initial Design – Each RT task executed in its own address space. • High overhead of context switching as TLB had to be invalidated. • High overhead of system calls. • Now all RT tasks run in the same address space (in the kernel space) and at the highest privilege level. • But highly error prone as a bug in a single application can wipe out entire system.

14. RT Linux – Tasks (Contd.) • RT tasks run as kernel modules. Can be dynamically added. • Tasks have integer context for faster context switching (unless FP context is explicitly requested). • Hardware context switching provided by x86 is not used. • Task resources should be statically allocated (kmalloc etc. should not be used within an RT task).

15. RT Linux - Scheduling • RT Linux is module based – the scheduler is itself a loadable kernel module. • Default – A simple preemptive priority based scheduler where the tasks are statically assigned priorities. The highest priority task ready to run is scheduled.

16. RT Linux – Scheduling (Contd.) • Alternate scheduling policies • Earliest Deadline First (EDF) – A dynamic priority scheduler in which the task with the nearest deadline is scheduled. • Rate Monotonic (RM) – A static priority scheduler for periodic tasks where the task with the smallest period is assigned the highest priority. This is provably the optimal policy.

17. RT Linux – Timing • Tradeoff between amount of time spent in handling clock interrupts with task release jitter (the difference between the exact time when the task should have been scheduled and the time at which it is actually scheduled). • So we program the timer chip to interrupt the CPU exactly when the next event has to be scheduled (one-shot mode).

18. RT Linux – Timing (Contd.) • Global time is kept track of by summing up all intervals between interrupts. • Time Stamp Counter (TSC) available on Pentiums can also aid in the process. • Conventional 10ms interrupts are simulated for Linux. • Normal periodic timer mode is also supported to avoid the overhead of reprogramming the clock every time.

19. Inter-Process Communication (IPC) • Linux kernel may be preempted by an RT task even during a system call, so no Linux routine can be safely called from real-time tasks. • RT fifos used for communication between RT tasks and Linux user processes. • RT fifo buffers are allocated in kernel address space.

20. IPC (Contd.) • RT fifos export lock-free functions for reading and writing on RT side and a standard device interface on the user side. • Static limit on the number of fifos. • Fifos should be used unidirectionally. A pair can be used for bidirectional transfer. • A handler can be associated with a fifo which is called when Linux task accesses it. • IPC using shared memory also available.

21. Using Shared Memory • mbuff module and /dev/mbuff device can be used for shared memory. • Linux tasks can map memory, allocated in the kernel using vmalloc(), to their address space. • The allocated memory is logically (but not physically) contiguous. • Cannot be swapped out, so is suited for communication between real time tasks and user space.

22. Queue data, no protocol needed to prevent overwrites. Message boundaries not maintained. Support blocking for synchronization, no polling required. Fifos are point-to-point channels. Maximum number of fifos statically defined. No queuing of data. Need to follow explicit protocol Can write structured data into memory. Need to poll for synchronization. Can have any number of tasks sharing memory. Physical memory is the only limit. RT Fifo vs. Shared Memory

23. Design of applications using RT Linux • It is envisaged that applications will consist of two parts. • The Real Time part should be fast, simple and small. • Other part will run in user space and should take care of I/O etc. • User task will communicate with real time task via real time fifos.

24. Structure of RT Application RT Fifo User Process RT Fifo X Windows Linux Kernel RT Process Display Disk Network Peripheral Device

25. Hello World in RT Linux pthread_t thread; void * start_routine(void * arg) { . . . } int init_module(void) { return pthread_create(&thread, NULL, start_routine, 0); } int cleanup_module(void) { pthread_delete(thread); }

26. Hello World (contd…) void * start_routine(void *arg) { struct sched_param p; p.sched_priority = 1; pthread_setschedparam(pthread_self(), SCHED_FIFO, &p); pthread_make_periodic_np(pthread_self(), gethrtime(), 500000000); while (1) { pthread_wait_np(); rtl_printf(“Hello World !\n”); } return 0; }

27. Using Interrupts • There are two types of interrupts : Hard and Soft. • Hard interrupts are the actual device interrupts and have less latency. • First RT handler (if any) is called and if it permits sharing, the interrupt is passed on to Linux. • Very limited set of kernel functions can be called from them.

28. Soft Interrupts • Soft interrupts are at par with normal Linux interrupts. • They don’t provide real time performance. • Kernel functions may be called from them. • Can be delayed for considerable periods of time. • Serviced when system switches back to Linux. • Used in implementation of RT fifos.

29. Writing Interrupts Driven Threads • A specific IRQ can be requested with rtl_request_irq(irq, handler, regs). • An IRQ can be released using rtl_free_irq(irq) • The “handler” executes with hardware interrupts disabled. • If it is necessary to receive further interrupts, re-enabling is done with rtl_hard_enable_irq(irq).

30. Interrupt Driven Threads (contd…) • An interrupt driven thread is created as usual by calling pthread_create(). • The thread calls pthread_suspend_np() and blocks. • It is assumed that the interrupt handler will call pthread_wakeup_np() to wakup this thread.

31. Using Floating Point Operations • By default RTL threads cannot use floating-point operations. • This is because RTL threads have an integer context only. • This has been done to facilitate fast context switches because switching FP context takes some time.

32. FP operations (contd…) • To change default status of floating point operations the following function needs to be called: pthread_setfp_np(thread,flag) • To enable use flag set to 1, to disable set flag to 0. • FP context is switched only if the new thread requires it.

33. Providing Mutual Exclusion • RT Linux supports the POSIX style pthread_mutex_ family of functions. • Internal implementation of lock and unlock uses spin-locks. • Currently there is no support for handling problems such as Priority Inversion, deadlocks etc.

34. Conclusion • RT Linux has achieved hard real-time performance by making minimal changes to a freely available Operating System. • Provides an alternative to proprietary real-time systems which may be prohibitively expensive. • As Linux develops, RT Linux will also ride the wave of its development. • Unlike other RT systems, no separate support for RT Linux is needed since support for Linux is already widely available.