real time system with mvl

Real Time System with MVL

© 2007 MontaVista Confidential | Overview of MontaVista

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


Things to know

H/W Delay Vectoring Dispatch ISR / Driver

Interrupt Latency

Off-time

Kernel Scheduler TaskInterrupt Latency Context Switch

Preemption or Task Response Latency


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

99

98

…

50

…

1

0(-19)

…

39(20)

Real-time processes

Normal processes

SCHED_OTHER

SCHED_FIFO

SCHED_FIFO

SCHED_RR

SCHED_RR

Dynamic priority

Static priority

SCHED_FIFO

* 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

Medium Prio Task (M)

Low Prio Task (L)

Kernel (scheduler)

Medium Prio Task x

High Priority Task (H)

Locks Mutex

Tries to get

Mutex

Unlocks Mutex

Gets 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

H/W Interrupt

Kernel (scheduler)

Running Task (L)

High Priority Task (H)

Minimized Latency

IRQ Thread wake-up


VoluntaryPreemption

PreemptibleKernel

Preemption mode comparison

Preemptible Non-Preemptible

No Preemption

Realtime Preemption


Improved latency


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.

SchedulerHighest PriorityOther tasks


Mistake: priority design

• 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?

0

99

regular apps

threaded IRQs

ksoftirqd

watchdogthread migration

Your RT app here???

non-RT app here???

© 2007 MontaVista Confidential | Overview of MontaVista 17

Mistake: “running at prio 99 froze my system”

testrt.c:

#include <pthread.h> int main(void) {

set_my_priority_to_highest(); while (true) {;} return 0;

}

or:

while (someVolatile != -1){ sched_yield();}

© 2007 MontaVista Confidential | Overview of MontaVista 18

Throughput High responsiveness

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


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 for Linux native applications

• Default Thread model : NPTL

• Priority Queueing for Mutex/Semaphore

• Priority Inheritance Mutex

• Robust Mutex

Questions and Answers

Thank You

real time system with mvl

Documents