Frequently Asked Questions

From RTwiki
(Difference between revisions)
Jump to: navigation, search
m (Do I need to recompile my applications to get realtime performance?)
(Create a general "Getting Started" section of the FAQ and move questions related to it there.)
Line 9: Line 9:
  
 
* [[User:jaswinderlinuxrt | Jaswinder Singh]]
 
* [[User:jaswinderlinuxrt | Jaswinder Singh]]
* [[User:Lfu | Luotao Fu]] (l.fu AT pengutronix DOT de), Pengutronix e.K., Kernel Development Group <br>
+
* [[User:Lfu | Luotao Fu]] (l.fu AT pengutronix DOT de), Pengutronix e.K., Kernel Development Group
* [[User:Rschwebel | Robert Schwebel]] (r.schwebel AT pengutronix DOT de), Pengutronix e.K., Kernel Development Group<br>
+
* [[User:Rschwebel | Robert Schwebel]] (r.schwebel AT pengutronix DOT de), Pengutronix e.K., Kernel Development Group
* [[User:Remy | Remy Bohmer]] (linux AT bohmer DOT net)<br>
+
* [[User:Remy | Remy Bohmer]] (linux AT bohmer DOT net)
 
* [[User:jaswinderlinuxrt | Jaswinder Singh]]
 
* [[User:jaswinderlinuxrt | Jaswinder Singh]]
* [[User:Tytso | Theodore Ts'o]]
+
* [[User:Tytso | Theodore Ts'o]] (tytso AT mit DOT edu), IBM
  
 
=== Table of Contents ===
 
=== Table of Contents ===
Line 19: Line 19:
 
__TOC__
 
__TOC__
  
==Realtime Support ==
+
== Getting Started ==
  
=== What is realtime support? ===
+
=== What is real-time? ===
  
TBA
+
Real-time applications have operational deadlines between some triggering event and the application's response to that event.  To meet these operational deadlines, programmers use real-time operationg systems which make minimum time guarantees between some event and code waiting for that event (assuming the thread which is waiting for that event is sufficiently high priority that it is eligible to run as soon as the event it is waiting for takes place).
 +
 
 +
=== What are real-time capabilities of the stock 2.6 linux kernel? ===
 +
 
 +
Traditionally, the Linux kernel will only allow one process to preempt another only under circumstances:
 +
 
 +
* When the CPU is running user-mode code
 +
* When kernel code returns from a system call or an interrupt back to userspace
 +
* When kernel code code blocks on a mutex, or explicitly yields control to another process
 +
 
 +
If kernel code is executing when some event takes place that requires a high priority thread to start executing, the high priority thread can not preempt the running kernel code, until the kernel code explicitly yields control.  In the worst case, the latency could potentially be hundreds milliseconds or more.
 +
 
 +
The 2.6 Linux kernel has a configuration option, CONFIG_PREEMPT, which will makes all kernel code outside of spinlock-protected regions and interrupt handlers preemptible.  With this option, worst case latency drops to single digit milliseconds, but some device drivers can have interrupt handlers that can introduce latency much worse than that.  If the real-time Linux application requires latencies faster then single-digit milliseconds, then they will need to use CONFIG_PREEMPT_RT patch.
  
=== How does realtime work? ===
+
=== How does the CONFIG_PREEMPT_RT patch work? ===
  
 
The RT-Preempt patch converts Linux into a fully preemptible kernel. The magic is done with:
 
The RT-Preempt patch converts Linux into a fully preemptible kernel. The magic is done with:
Line 34: Line 46:
 
* Converting the old Linux timer API into separate infrastructures for high resolution kernel timers plus one for timeouts, leading to userspace POSIX timers with high resolution.  
 
* Converting the old Linux timer API into separate infrastructures for high resolution kernel timers plus one for timeouts, leading to userspace POSIX timers with high resolution.  
  
more information: [[RT PREEMPT HOWTO]]
+
=== How to start using the CONFIG_PREEMPT_RT patch? ===
  
=== What is the procedure to add realtime support? ===
+
Please see the [[RT PREEMPT HOWTO]] for a detailed description.  The short version is to get the latest -rt patch from http://www.kernel.org/pub/linux/kernel/projects/rt/, then get the related vanilla kernel from http://kernel.org, apply the patch to the kernel, configure, and compile the kernel.
  
Download latest realtime preemption patch from http://www.kernel.org/pub/linux/kernel/projects/rt/ then get related vanilla kernel from http://kernel.org/ then patch, configure and compile
+
=== What mailing lists are available to discuss the CONFIG_PREEMPT_RT patch? ===
  
 +
Please see [[Mailinglists | the mailing lists]] page in the rt wiki.
  
==Architecture==
+
 
 +
== Architecture ==
  
 
=== Which Architecture are supporting realtime and who is maintainer? ===  
 
=== Which Architecture are supporting realtime and who is maintainer? ===  
Line 107: Line 121:
 
TBA
 
TBA
  
== Mailing list ==
 
  
=== realtime mailing list and archives ===
 
  
http://www.mail-archive.com/linux-rt-users@vger.kernel.org/
+
== Configuring/compiling questions ==
  
=== If I have some doubts or problems regarding realtime, do I need to send mail in realtime mailing list or linux kernel mailing list or both? ===
+
=== How to enable/disable realtime support? ===
  
 
TBA
 
TBA
  
 
+
=== Change realtime support run time or statically? ===
== Realtime Patches questions==
+
 
+
=== Why I need to download realtime patches, If realtime support is in Linux kernel? ===
+
  
 
TBA
 
TBA
 
=== Where can I download latest realtime patches? ===
 
 
http://www.kernel.org/pub/linux/kernel/projects/rt/
 
 
=== Where can I post my realtime patches? ===
 
 
Please send patches for the CONFIG_PREEMPT_RT Patch Set to LKML and put Ingo Molnar and Thomas Gleixner on CC.
 
 
Please do not send clocksource and clockevents related patches against the -rt patch. Make sure they apply against the latest -hrt-dyntick patch. -hrt-dyntick might be a bit ahead of -rt at times, but the -rt patch pulls -hrt-dyntick on a regular base.
 
 
more information: [[CONFIG_PREEMPT_RT Patch]]
 
 
 
==Configuring/compiling questions==
 
 
=== How to enable/disable realtime support? ===
 
 
TBA
 
 
=== Change realtime support run time or statically? ===
 
  
 
=== Required parameters for configuring realtime kernel? ===
 
=== Required parameters for configuring realtime kernel? ===

Revision as of 01:58, 30 September 2007

Intro

This page contains a list of frequently asked questions about the real-time support in the Linux Kernel


Acknowledgements

Authors of this FAQ include:

Table of Contents

Contents


Getting Started

What is real-time?

Real-time applications have operational deadlines between some triggering event and the application's response to that event. To meet these operational deadlines, programmers use real-time operationg systems which make minimum time guarantees between some event and code waiting for that event (assuming the thread which is waiting for that event is sufficiently high priority that it is eligible to run as soon as the event it is waiting for takes place).

What are real-time capabilities of the stock 2.6 linux kernel?

Traditionally, the Linux kernel will only allow one process to preempt another only under circumstances:

  • When the CPU is running user-mode code
  • When kernel code returns from a system call or an interrupt back to userspace
  • When kernel code code blocks on a mutex, or explicitly yields control to another process

If kernel code is executing when some event takes place that requires a high priority thread to start executing, the high priority thread can not preempt the running kernel code, until the kernel code explicitly yields control. In the worst case, the latency could potentially be hundreds milliseconds or more.

The 2.6 Linux kernel has a configuration option, CONFIG_PREEMPT, which will makes all kernel code outside of spinlock-protected regions and interrupt handlers preemptible. With this option, worst case latency drops to single digit milliseconds, but some device drivers can have interrupt handlers that can introduce latency much worse than that. If the real-time Linux application requires latencies faster then single-digit milliseconds, then they will need to use CONFIG_PREEMPT_RT patch.

How does the CONFIG_PREEMPT_RT patch work?

The RT-Preempt patch converts Linux into a fully preemptible kernel. The magic is done with:

  • Making in-kernel locking-primitives (using spinlocks) preemptible though reimplementation with rtmutexes:
  • Critical sections protected by i.e. spinlock_t and rwlock_t are now preemptible. The creation of non-preemptible sections (in kernel) is still possible with raw_spinlock_t (same APIs like spinlock_t)
  • Implementing priority inheritance for in-kernel spinlocks and semaphores. For more information on priority inversion and priority inheritance please consult Introduction to Priority Inversion
  • Converting interrupt handlers into preemptible kernel threads: The RT-Preempt patch treats soft interrupt handlers in kernel thread context, which is represented by a task_struct like a common userspace process. However it is also possible to register an IRQ in kernel context.
  • Converting the old Linux timer API into separate infrastructures for high resolution kernel timers plus one for timeouts, leading to userspace POSIX timers with high resolution.

How to start using the CONFIG_PREEMPT_RT patch?

Please see the RT PREEMPT HOWTO for a detailed description. The short version is to get the latest -rt patch from http://www.kernel.org/pub/linux/kernel/projects/rt/, then get the related vanilla kernel from http://kernel.org, apply the patch to the kernel, configure, and compile the kernel.

What mailing lists are available to discuss the CONFIG_PREEMPT_RT patch?

Please see the mailing lists page in the rt wiki.


Architecture

Which Architecture are supporting realtime and who is maintainer?

Processor Supported Contact(s)
alpha
arm Yes
arm26
avr32
blackfin
cris
frv
h8300
i386 Yes
ia64
m32r
m86k No
m68knommu No
mips
parisc
powerpc Yes
ppc
s390
sh
sh64
sparc
sparc64
um
v850
x86_64 Yes
xtensa


What is the procedure to support realtime in new architecture?

TBA


Configuring/compiling questions

How to enable/disable realtime support?

TBA

Change realtime support run time or statically?

TBA

Required parameters for configuring realtime kernel?

TBA

Optional parameters for configuring realtime kernel, but they effect realtime performance?

TBA


Realtime samples/Performance questions

What effects by realtime support and how much and samples to test it and who maintains these samples?

Area Effected by Realtime(%) Samples Contact(s)
scheduling
Interrupt latency
IPC
Filesystem
Device drivers
Network
X-Windows


Realtime Applications questions

List of realtime APIs?

TBA

How to write realtime applications?

TBA

Which programming languages are suitable for writing realtime applications?

It depends on your latency requirements, but usually these are advisable:

What are important things to keep in mind while writing realtime applications?

Taking care of the following during the initial startup phase:

  • Call directly from the main() entry the mlockall() call.
  • Create all threads at startup time of the application, and touch each page of the entire stack of each thread. Never start threads dynamically during RT show time, this will ruin RT behavior.
  • Never use system calls that are known to generate pagefaults, such as fopen(). (Opening of files does the mmap() system call, which generates a page-fault).
  • Do not use 'compile time static arrays' without initializing them directly after startup, before RT show time.

more information: HOWTO: Build an RT-application

Do I need to recompile my applications to get realtime performance?

Recompile is not necessary. Userland does not notice any difference if it is running on RT or not, except for a much better RT-responsiveness, only changing the kernel is enough.

But, usually, locking bugs in userland applications become much more visible due the more dynamic and fine grained scheduling of the kernel. These are not new bugs, but bugs already existing in the applications, which only become visible on RT (Notice that these bugs are also likely to occur on SMP systems).

Also:

  • A bad designed application on non-RT will never behave realtime on RT. See also HOWTO: Build an RT-application.
  • Never protect shared/global data in userland processes with semaphores (yes, many people do that...), but use PTHREAD_PRIO_INHERIT mutexes instead. (PTHREAD_PRIO_INHERIT mutexes are only supported in Glibc 2.5 and higher. uClibc based filesystems do not support this)

Maintainers questions

Who are the Maintainers of realtime kernel patch?

Personal tools