Frequently Asked Questions

From RTwiki
(Difference between revisions)
Jump to: navigation, search
(Hardware causes of ISR latency)
Line 19: Line 19:
<p>FAQ for realtime support in Linux Kernel</p>
<p>FAQ for realtime support in Linux Kernel</p>
Question Index
Question Index
1. Realtime Support questions
1. Realtime Support questions
Line 29: Line 29:
7. Realtime Applications questions
7. Realtime Applications questions
8. Maintainers  questions
8. Maintainers  questions
===Latencies caused by Page-faults===
Whenever the RT process runs into a page-fault the kernel freezes the entire process (with all its threads in it), until the kernel has handled the page fault. There are 2 types of pagefaults, major and minor pagefaults. Minor pagefaults are handled without IO accesses. Major pagefaults are pagefaults that are handled by means of IO activity.
Page faults are therefor dangerous for RT applications and need to be prevented.
If there is no Swap space used, and no other applications stress the memory boundaries, then there is enough free RAM ready for the RT application to be used. In this case the RT-application will only run into minor pagefaults, which cause relatively small latencies.
But, if the RT application is just one of the many applications on the system, and there is Swap space used, then special actions has to be taken to protect the memory of the RT-application.
If memory has to be retrieved from disk or pushed towards the disk to handle a page fault, the RT-application will experience very large latencies, sometimes up to more than a second! Notice that pagefaults of one application cannot interfere the RT-behavior of another application.
During startup a RT-application will always experience a lot of pagefaults. These cannot be prevented. In fact, this startup period must be used to claim and lock enough memory for the RT-process in RAM. This must be done in such a way that when the application needs to expose its RT capabilities, pagefaults do not occur anymore.
This can be done by 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.
====File handling====
File handling is known to generate disastrous pagefaults. So, if there is a need for file access from the context of the RT-application, then this can be done best by splitting the application in an RT part and a file-handling part. Both parts are allowed to communicate through sockets. I have never seen a page fault caused by socket traffic.
Note: While accessing files the low-level fopen() call will do a mmap() to allocate new memory to the process, resulting in a new pagefault.

Revision as of 14:30, 29 September 2007




Jaswinder Singh


Revision History
Revision 1 2007-09-29
Draft / Work in progress


FAQ for realtime support in Linux Kernel


Question Index 1. Realtime Support questions 2. Architecture questions 3. Mailing list questions 4. Realtime Patches questions 5. Configuring/compiling questions 6. Realtime samples/Performance questions 7. Realtime Applications questions 8. Maintainers questions

Personal tools