220 likes | 430 Views
Real Time System with MVL. Agenda. Why Linux Real Time? Linux Kernel Scheduler Linux RT technology Making Real-Time systems MontaVista’s Solution for Real Time. Why Linux Real Time?. Linux is good because It is open source It is robust It is feature rich And much more…
E N D
Agenda • Why Linux Real Time? • Linux Kernel Scheduler • Linux RT technology • Making Real-Time systems • MontaVista’s Solution for Real Time
Why Linux Real Time? • Linux is good because • It is open source • It is robust • It is feature rich • And much more… • However Real Time is also needed for some applications • Requiring deterministic response time
Interrupt Latency H/W Delay Vectoring Off-time Kernel Scheduler Dispatch ISR / Driver Interrupt Latency Task Context Switch Preemption or Task Response Latency Things to know
Linux Kernel Scheduler • O(1) Scheduler • Deterministic scheduler overhead regardless of # of tasks • Supports task priority: 0 ~ 99 default • Supports scheduling policy • SCHED_OTHER, SCHED_RR and SCHED_FIFO • The default scheduler for Linux 2.6.x kernels • Reduces scheduling latency • Completely Fair Scheduler (CFS)? • It is not for Real Time applications • Good for server and desktop
Priority based scheduling Static priority 99 98 … 50 …10(-19) … 39(20) SCHED_FIFO SCHED_RR SCHED_FIFO SCHED_FIFO SCHED_RR Real-time processes Normal processes SCHED_OTHER Dynamic priority * Nice value is not a static priority
Preemptive Kernel • Introduced by Rover Love (former MontaVista employee) • Utilizes spin_lock / spin_unlock to protect kernel critical sections • Supports kernel preemption • Reduces preemption latency • Preemption point • At the end of interrupt handler • At the end of system call • At the end of spin_unlock • But not in between spin_lock and spin_unlock
Voluntary Preemption • By Ingor Molnar (RedHat) • Adds more ‘explicit preemption points’ • Minimize the maximum latency of rescheduling • Reduces preemption latency • might_sleep() is the key • You can find many of this calls in the kernel source • Normally in the loop code • Valid only when CONFIG_PREEMPT_VOLUNTARY is set
Mutual Exclusion (MUTEX) • Priority Inheritance Mutex – Kernel • Converts spin_lock to priority inheritance mutex • When CONFIG_PREEMPT_RT is set • Transparent to kernel code: syntax is still same • Enables preemption between spin_lock and spin_unlock • New raw_spinlock_t • Should be used where mutex can not be used • Syntax is still same: spin_lock and spin_unlock • Spin_lock appropriately handles it depending on the type • Fast User Mutex (FUTEX) – Applications • Utilizes kernel priority inheritance mutex • No kernel call when there is no contention
Priority Inheritance Mutex Locks Mutex Unlocks Mutex Kernel (scheduler) Low Prio Task (L) Medium Prio Task (M) Medium Prio Task x High Priority Task (H) Gets Mutex Tries to get Mutex
Threaded Interrupt Handler • Interupt handler is called by a kernel interrupt handler thread • The interrupt handler thread is assigned a task priority • Minimizes interrupt latency thus preemption latency as well • Does not content with RT tasks • Flexible system design • Can assign a higher priority on an important task • Default for PREEMPT_RT and optional for others • IRQF_NODELAY is needed • For timers and etc. • Interrupt handler can not make use of spin_lock
Threaded Interrupt Handler (2) IRQ Thread wake-up Kernel (scheduler) H/W Interrupt IRQ Thread Running Task (L) High Priority Task (H) Minimized Latency
No Preemption Voluntary Preemption Preemptible Kernel Realtime Preemption Preemptible Non-Preemptible Preemption mode comparison
System Design Theory • You should only have one highest priority process* • IO-bound • control algorithms are IO-bound: they start and end with IO • Finite time running guarantee on your process • Definitely NO infinite loops! • sum(total running time + 2 x scheduler run) < latency req. Scheduler Highest Priority Other tasks
Be careful! Ksoftirqd manages: High-res timers NAPI (network!) Some blockdevice stuff IRQs might have wrong prio Does your RT apps needsomething from (soft)IRQs? Mistake: priority design 99 watchdog thread migration Your RT app here??? threaded IRQs ksoftirqd non-RT app here??? 0 regular apps
testrt.c: #include <pthread.h> int main(void) { set_my_priority_to_highest(); while (true) {;} return 0; } • or: • while (someVolatile != -1) { sched_yield(); } Mistake: “running at prio 99 froze my system”
Real-Time Response vs. Throughput Efficiency and Responsiveness are Inversely Related Overhead for Real-Time Preemption • Mutex Operations more complex than Spinlock Operations • Priority Inheritance on Mutex increases Task Switching • Priority Inheritance increases Worst-Case Execution Time Design flexibility allows much better worst case scenarios • Real-time tasks are designed to use kernel resources in managed ways then delays can be eliminated or reduced Throughput High responsiveness
MontaVista Linux 5.0 Real-Time • Kernel features for Real-Time • All previous features plus more… • Kernel 2.6.18 (+2.6.19 & 20 backports) • Real-Time forLinux native applications • Default Thread model : NPTL • Priority Queueing for Mutex/Semaphore • Priority Inheritance Mutex • Robust Mutex Native Hard RealTime!