我正在考虑将我的产品从 RTOS 转移到嵌入式 Linux。我对实时性的要求不多，很少有RT要求在10s毫秒量级。

谁能告诉我当前版本的 Linux 的实时性如何？

从商业 RTOS 迁移到 Linux 是否还有其他问题？

最佳答案

您可以从实时 Linux wiki 中获得大部分答案。和 FAQ

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 certain circumstances:

• When the CPU is running user-mode code
• When kernel code returns from a system call or an interrupt back to user space
• 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 Linux 2.6 configuration option CONFIG_PREEMPT_VOLUNTARY introduces checks to the most common causes of long latencies, so that the kernel can voluntarily yield control to a higher priority task waiting to execute. This can be helpful, but while it reduces the occurences of long latencies (hundreds of milliseconds to potentially seconds or more), it does not eliminate them. However unlike CONFIG_PREEMPT (discussed below), CONFIG_PREEMPT_VOLUNTARY has a much lower impact on the overall throughput of the system. (As always, there is a classical tradeoff between throughput --- the overall efficiency of the system --- and latency. With the faster CPU's of modern-day systems, it often makes sense to trade off throughput for lower latencies, but server class systems that do not need minimum latency guarantees may very well chose to use either CONFIG_PREEMPT_VOLUNTARY, or to stick with the traditional non-preemptible kernel design.)

The 2.6 Linux kernel has an additional configuration option, CONFIG_PREEMPT, which causes all kernel code outside of spinlock-protected regions and interrupt handlers to be eligible for non-voluntary preemption by higher priority kernel threads. With this option, worst case latency drops to (around) single digit milliseconds, although some device drivers can have interrupt handlers that will introduce latency much worse than that. If a real-time Linux application requires latencies smaller than single-digit milliseconds, use of the CONFIG_PREEMPT_RT patch is highly recommended.

他们还有一个您在常见问题解答中称呼他们的“陷阱”列表。

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

Taking care of the following during the initial startup phase:

• Call mlockall() as soon as possible from main().
• 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 page faults, such as fopen(). (Opening of files does the mmap() system call, which generates a page-fault).
• If you use 'compile time global variables' and/or 'compile time global arrays', then use mlockall() to prevent page faults when accessing them.

more information: HOWTO: Build an RT-application

他们还有一个很大的publications page你可能想结账。

关于linux - "Real-Time"怎么是Linux 2.6？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1362906/