问题标签 [preempt-rt]

我正在尝试构建和安装 Raspberry Pi RT Preempt Linux Kernel。

这些是我遵循的步骤：

1. 我安装了预编译的内核kernel-4.4.9-rt17.tgz

2. 我下载了 Raspberry Pi 内核源代码并应用了 Real Time patch-4.4.9-rt17.patch.gz。

3. 我使用以下命令为 Raspberry Pi3，B 型配置了我的内核：

   /li>

4. 我将内核配置为支持完全可抢占内核（RT），使用

   /li>

5. 我使用构建内核

   但我收到了错误：

   /li>

这是内核构建输出

你有什么想法来解决这个问题吗？我不知道我做错了什么。我已经坚持了一段时间了，非常感谢任何帮助。

我收到错误：mlockall failed: 调用函数 mlockall() 时无法分配内存：

使用的 IDE：Eclipse 操作系统：Ubuntu 16.04 实时扩展使用：4.11.12 rt-15（抢占补丁） 注意：我正在尝试实时进行 UDP 连接（使用英特尔 i210 以太网控制器）。

当我在 Eclipse 中调试相同的内容时，显示的是：

在“/build/glibc-bfm8X4/glibc-2.23/misc/../sysdeps/unix/syscall-template.S”中找不到源文件找到文件或编辑源查找路径以包含其位置。

如何解决这个问题？

根据Linux源代码和这个主题： 系统调用是否完全在软件中断处理程序中执行？

似乎某些系统调用完全在中断处理程序内部处理（不考虑 vDSO 系统调用）。这意味着系统调用会阻塞所有其他任务的执行，直到它阻塞信号量或导致产量。

我的问题：Linux PREEMPT_RT 补丁是否纠正了这些调用以及如何纠正？

文档说：

将中断处理程序转换为可抢占的内核线程：RT-Preempt 补丁在内核线程上下文中处理软中断处理程序，它由一个 task_struct 表示，就像一个常见的用户空间进程。但是，也可以在内核上下文中注册一个 IRQ。

（来源：https ://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions ）

它似乎被推迟到一个线程，但修补的 Linux 内核中的 swi_handler 代码（arm）仍然调用处理程序中的 sys_* 函数。

假设系统调用由具有特权的内核线程（ring 0 / supervisor）处理，这个内核线程是否具有与调用线程相同的执行优先级？

避免优先级倒置是有意义的。

在尝试调度高速线程时，我注意到有时有很长一段时间（多个毫秒）没有调度线程。我想知道在我正在使用的配置中可以对调度程序执行此操作。

• 带有 RT (i686) 的最新 Debian 伸展（稳定）
• 双核英特尔 (2237MHz)
• PS2 键盘和鼠标
• CPU 1 保留（通过 grub）
• 用于将我的测试过程放在核心 1 上的任务集
• SMI 禁用、速度步禁用等（典型的 RT BIOS 设置）
• USB 端口未禁用但未插入任何内容
• IRQ 平衡禁用

我确认 CPU1 上只有 worker、timer 等。其他一切都在 CPU0 上。

我的线程是 SCHED_DEADLINE（唯一一个这样安排的线程），周期为 300us。我使用 schedules_yield() 在预订完成之前很久就释放线程（只是一个测试循环），所以我确定它没有过度运行。

我得到的是一个近乎完美的 3333Hz 输出（通过 o-scope），它时不时地被阻塞，每次超过 15 毫秒。我已经查看了中断（除了计时器，在那个 CPU 上没有递增），我已经禁用了 NMI 中断等等，但没有找到干扰进程是什么。我不相信我完全理解什么可以优先考虑并导致调度程序跳过周期所以我希望有人可能有一个想法？

我认为这可能是磁盘 IO，但这似乎与差距不符（有时确实如此......）。VGA/控制台的使用似乎使情况变得更糟，但即使不使用，差距仍然存在。

是的，在你问之前......这只是一个实验，看看这是否可以可靠地完成。我的实际代码在 QNX 上运行，它在同一硬件上以这种速度稳定运行。我正在试验是否可以使用 PREEMPT_RT 将其移植到 Debian。

谢谢！

我正在使用 hwlat_detector 跟踪器来测量在 Linux 之外引起的系统延迟。

用于测量的机器是华硕 Zenbook ux331un。我确实使用 idle=poll 内核命令行参数禁用了处理器电源状态，禁用了超线程，禁用了涡轮增压。这是 hwlat 跟踪器的示例输出。

从输出中可以看出，发生了超过 400us 的延迟。我在 30us 范围内也有很多延迟。起初我认为延迟是由 SMI 引起的，所以我开始读取 MSR 寄存器 0x​​34，它计算自系统启动以来发生的 SMI 数量。测试运行时它不会增加。还有什么可能是这种延迟的原因？

我正在使用带有 preempt-rt 补丁的 Linux 内核，我做了一个简单的测试来测量中断和向用户空间通知中断之间的时间。这个想法很简单，我有一个模块，它实现了读取：

然后从中断例程中唤醒读取：

静态 irqreturn_t

打印的值约为 65 和 70，例如

myproc-532 [002] ....... 8049.789350：0xbf0c81f0：wake_up_interruptible 65

我的CPU是4核：

型号名称：ARMv7 处理器 rev 10 (v7l) BogoMIPS：7.54

和频率是

猫 /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 996000

我认为 65-70 我们几乎可以唤醒一个过程。

我尝试使用 chrt 更改 irq 和进程优先级，并使用 smp_affinity 将 irq 降级到特定的核心，并使用 taskset 处理到相同的核心或不同的核心，但结果基本上没有改变。

我究竟做错了什么？

我目前正在构建实时 IPC 系统。

我正在尝试构建一个没有所有不确定组件的实时系统。

我尝试基于共享内存模型设置 IPC。

使用 boost 库中的 managed_shared_memory 来最小化不可预测的延迟是否安全？还是应该使用 mmap() 进行内存共享？

还有从 SIGRTMIN 到 SIGRTMAX 的通道的 rt_signal 可以安全使用吗？

谢谢！顺便说一句，我在 preempt-rt 修补的 linux 内核上使用它们。

我正在研究比较 linux 默认内核和使用 preempt_rt 修补的内核。我使用了很多工具（stress-ng、T-Sui、CPU burn、cycletest）来检查补丁的有效性。但我可以看到默认内核确实已经提供了一种将任务优先级更改为“实时任务”的方法。因此，所有压力测试都显示出类似的结果：我的应用程序始终作为实时任务执行，没有任何严重的延迟或令人惊讶的不同......

我知道 preempt_rt 导致的一些差异（比如中断移动到线程上下文，内核中的非抢占代码较少）但是我该如何测试它们呢？ 我已经看到正常的压力工具对我的实时应用程序几乎没有影响......是否有任何工具可以执行一种“高非抢占内核代码”或触发大量中断？

我正在尝试制作一个实时的进程间通信模块。

为了避免无限的优先级反转、死锁和链阻塞，我为每个互斥体设置了 PTHREAD_PRIO_PROTECT。

下面是每个互斥锁的初始化方式

正好有两个互斥锁(m1 & m2) 有两个以上的线程(t1, t2, ..., tn)

现在我特意给出了一个死锁情况，有些线程先锁m1再锁m2，而其他线程先锁m2再锁m1

并且为每个互斥体设置了优先级上限协议，死锁情况不应该发生但是，它似乎仍然会发生。

你有什么主意吗？我是否错误地执行它？

顺便说一句，每个线程都设置有 SCHED_FIFO 和一些优先级值 1 ~ 95

在禁用 CONFIG-MIGRATION 和 CONFIG-COMPACTION 时，Linux 内核是否可以使用一些方法来确定页面分配失败的概率？

除了增加 min_free_bytes 的值和执行之外，是否有一些系统设置可以实现这个目标echo 2 > /proc/sys/vm/drop_caches？

这是页面分配失败的示例日志：