问题标签 [preempt-rt]

我正在尝试从 POSIX 中的 ExpressLogic 移植实时 Thread_Metric，以便为我的论文对 Linux、Xenomai 和 RTAI 的 PREEMPT_RT 补丁进行基准测试。它们提供了具有以下功能的 C 源文件，您必须实现这些功能才能使基准测试工作：

现在我正在尝试实现 tm_thread_suspend 和 tm_thread_resume 函数，它们将 pthread 作为输入。我知道您可以使用 pthread_mutex_lock 和 pthread_cond_wait 例程挂起 pthread，但是您必须从线程 start_function 调用它们。我是这种东西的新手，而且我已经过头了。任何帮助表示赞赏。

我需要比较 preempt_rt 补丁、Xenomai 和 RTAI 之间的性能。他们每个人都有自己的基准，但他们没有给出相似的结果，而且并非所有的基准都适用于所有三个平台。我正在寻找的是一个可以测量基本性能的基准，例如中断延迟、上下文切换时间等，它将在所有三个平台上运行。我尝试实现一个 Thread-Metric基准，但它对我来说太复杂了。任何人都知道是否存在这样的基准？提前感谢您的帮助。

目标硬件平台的马力有限，和/或您希望实时作业在您的系统上施加尽可能小的开销。这就是双内核通常比原生抢占系统更好的地方。

从这里：http ://www.xenomai.org/index.php/Xenomai:Roadmap#Xenomai_3_FAQ

Preempt_rt 确实抢占了整个 Linux。抢占 Linux 以何种方式给系统增加负载？

与 Xenomai 相比，FAQ 那里讨论了 preempt_rt。

来自：https ://rt.wiki.kernel.org/articles/f/r/e/Frequently_Asked_Questions_7407.html

实时只对内核有影响；除了更好的实时行为外，用户空间不会注意到差异。

这是否意味着如果我们在用户空间编写应用程序，它们将不会获得硬实时效果？

假设我有两个任务，“A”和“B”，在 SMP 支持的 VxWorks 上执行不同的优先级。“A”和“B”都向 I/O 设备（例如磁盘或 NIC）发出命令，并且都阻塞等待结果。也就是说，“A”和“B”同时被阻塞。一段时间后，I/O 设备引发中断并调用 ISR。然后 ISR 将延迟的工作（也称为“下半部分”）分派给工作任务。问题：worker-task 的优先级是多少？

VxWorks Device Driver Developer's Guide 有点含糊。似乎工作任务的优先级是先验设置的。没有自动继承机制可以根据阻塞等待结果的任务（“A”和“B”）的优先级来增加工作任务的优先级。这类似于 PREEMPT_RT Linux 中线程中断优先级的工作方式。但是，QNX Neutrino 和 LynxOS 都会以被阻塞任务的最高优先级调度工作任务——例如。优先级（工人）= max_priority（A，B）。

谁能澄清一下？

我正在开发一个嵌入式 Linux 项目，使用可能在 3.3 版左右的 arago 发行版。

我已经配置了一个高分辨率的 Linux 计时器，每毫秒唤醒一次我的进程。这工作正常，但时间有两个问题：

1. 唤醒时间的抖动
2. 尽管进程完成的处理是恒定的，但清醒时处理时间的可变性。

我将这些问题归咎于 Linux 的实时性能不佳。但我需要研究提高实时性能的方法。

我检查了内核是否配置了 CONFIG_PREEMPT 内核选项，这对实时很有用。

我还将 SCHED_FIFO 调度类应用于我的进程：

但这并没有什么不同。

我想一个合乎逻辑的步骤是将 PREEMPT_RT 补丁应用于内核构建，但我还没有确定如何做到这一点。

我还能做些什么来改善抖动/持续时间的可变性吗？

或者任何人都可以建议一个关于如何应用 PREEMPT_RT 补丁的可访问教程？

我正在尝试在 Raspberry Pi 中按原样对 Xenomai、PREEMPT_RT 和 Linux 进行基准测试，但遇到了一些麻烦。

我正在尝试创建可变数量的线程，具有 RT 优先级和可变的睡眠时间。其中一个线程具有较高的 RT 优先级，从 GPIO 读取，并写入另一个 GPIO（以读取示波器或类似设备上的延迟），而具有较低 RT 优先级的其他线程仅执行算术运算。GPIO 映射到内存上，因此可以避免协议开销。

我在这个测试中考虑： 1 线程 1 us 50 线程 10 us 100 线程 100 us 150 线程 1 ms 200 线程 10 ms 250 线程 100 ms

问题是只创建了一些线程。当线程数很高时，就会出现内存问题并且进程停止。那么，我应该如何进行呢？是代码不对，是时间太短，还是线程数太高？

这是代码：

我正在尝试描述 Linux 上的计时器抖动。我的任务是运行 100 毫秒的计时器，看看数字是如何计算的。

我正在开发一台多核机器。我使用带有 setitimer() 的标准用户程序，以 root 身份运行，然后使用处理器亲和性，最后使用处理器亲和性和进程优先级。然后我使用 PREEMPT_RT 内核运行相同的程序，然后使用 clock_nanosleep() 运行示例，就像 PREEMPT_RT 页面上的演示代码一样。在所有运行中，计时器的性能非常相似，尽管发生了变化，但没有真正的区别。

我们的最终目标是一个稳定的计时器。我能经常得到的最好的最坏情况是大约 200us。所有情况的直方图都显示出非常奇怪的行为。一方面，我不希望计时器提前触发。但他们确实如此。正如您在直方图中看到的那样，我在 0 偏移量的任一侧都有低谷。这些在第二张图中的三个波段中可见。在第一张图中，X 轴以微秒为单位。在第二张图中，Y 轴以微秒为单位。

我运行 30 秒测试（即 300 个计时器事件）100 次以生成一些数字。您可以在下图中看到它们。200us 有很大的下降。所有 30000 个计时器事件时钟偏移都显示在第二张图中，您可以在其中看到一些异常值。

那么问题来了，之前有没有其他人做过这种分析？你看到过同样的行为吗？我的假设是 RT 内核有助于负载重的系统，但在我们的例子中，它无助于消除定时器抖动。那是你的经历吗？

这是代码。就像我之前说的，我修改了 PREEMPT_RT 站点上使用 clock_nanosleep() 函数的示例代码，所以我不会包括我的最小更改。

编辑：这是在 Xeon E31220L 上，运行频率为 2.2 GHz，运行 x86_64 Fedora Core 19。

我目前正在使用 PREEMPT_RT 修补 Linux 系统（包括 librt 和 libpthread），从时间的角度来看，我的实时线程似乎工作相当可靠。在访问共享资源时，什么机制适合防止竞争条件？在我的情况下，我想在实时和非实时线程（例如 telnet 接口）之间共享统计信息。

例如。恕我直言，如果互斥锁被非实时任务锁定并且实时任务必须等待它。有没有替代方案或更好的方法？

我正在为 beaglebone black 构建一个自定义内核。按照本指南（http://android.serverbox.ch/?p=1273），我可以使用基本映像成功启动到控制台。

当我尝试使用命令构建实时内核补丁时：

我收到以下错误消息：

我在 README 文件中应用了建议（或者认为我做了......）：

但仍然收到相同的错误消息。
有没有人在使用 Yocto 构建实时内核方面取得任何成功？无法在任何地方为此找到明确的程序。