当前位置：文江博客话题详情

如何“实时”是Linux 2.6吗？

发布于 2024-08-03 08:19:29 字数 153 浏览 5 评论 0原文

我正在考虑将我的产品从 RTOS 迁移到嵌入式 Linux。我对实时性的要求并不高，少数的 RT 要求都是 10 毫秒左右。

有人可以给我指出一个参考资料，告诉我当前版本的 Linux 的实时性如何吗？

从商业 RTOS 迁移到 Linux 还存在其他问题吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

没有你我更好 2024-08-10 08:19:29

您可以从 Real Time Linux wiki 和常见问题解答

现有 2.6 Linux 内核的实时功能是什么？
传统上，Linux 内核仅在某些情况下才允许一个进程抢占另一个进程：
当 CPU 运行用户模式代码时
当内核代码从系统调用或中断返回到用户空间时
当内核代码代码在互斥锁上阻塞，或显式将控制权交给另一个进程时
如果内核代码正在执行时发生某些需要高优先级线程开始执行的事件，则高优先级线程无法抢占正在运行的内核代码，直到内核代码显式让出控制权。在最坏的情况下，延迟可能会达到数百毫秒或更长。
Linux 2.6 配置选项 CONFIG_PREEMPT_VOLUNTARY 引入了对导致长时间延迟的最常见原因的检查，以便内核可以自愿将控制权交给等待执行的更高优先级任务。这可能会有所帮助，但是虽然它减少了长延迟（数百毫秒到可能数秒或更长时间）的发生，但并不能消除它们。然而，与 CONFIG_PREEMPT（下面讨论）不同，CONFIG_PREEMPT_VOLUNTARY 对系统整体吞吐量的影响要小得多。（与往常一样，吞吐量（系统的整体效率）和延迟之间存在经典的权衡。随着现代系统的 CPU 速度更快，通常需要权衡吞吐量以降低延迟，但服务器不需要最小延迟保证的类系统很可能选择使用 CONFIG_PREEMPT_VOLUNTARY，或者坚持使用传统的非抢占式内核设计。）
2.6 Linux 内核有一个额外的配置选项 CONFIG_PREEMPT，它使自旋锁保护区域和中断处理程序之外的所有内核代码都有资格被更高优先级的内核线程非自愿抢占。使用此选项，最坏情况下的延迟会下降到（大约）个位数毫秒，尽管某些设备驱动程序可能具有中断处理程序，这会导致比这更糟糕的延迟。如果实时 Linux 应用程序需要小于个位数毫秒的延迟，强烈建议使用 CONFIG_PREEMPT_RT 补丁。

他们还有一个“陷阱”列表，正如您在常见问题解答中所说的那样。

需要保留哪些重要内容
实时写作时的思维
应用程序？
期间注意以下事项
初始启动阶段：
尽快从 main() 调用 mlockall()。
在应用程序启动时创建所有线程，并触摸每个线程的整个堆栈的每个页面。切勿在 RT 显示期间动态启动线程，这会破坏 RT 行为。
切勿使用已知会产生页面错误的系统调用，例如
fopen()。（打开文件会
mmap() 系统调用，它生成一个
页面错误）。
如果您使用“编译时全局变量”和/或“编译时全局变量”
数组'，然后使用 mlockall() 来
防止访问时出现页面错误
他们。
更多信息：HOWTO：构建一个
RT-应用

他们还有一个您可能需要的大型出版物页面去结帐。

You can get most of your answers from the Real Time Linux wiki and 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.

They also have a list of "Gotcha's" as you called them in the FAQ.

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