了解 RHEL for Real Time

实时处理器内核是物理中央处理单元(CPU)，它执行机器代码。套接字是处理器和计算机的主板之间的连接。套接字是处理器要放入的主板上的位置。有两组处理器：

在设计实时环境时，请注意可用内核的数量、核心中的缓存布局以及内核物理连接的方式。

当有多个内核可用时，请使用线程或进程。程序在没有使用这些构造的情况下编写，一次在一个处理器上运行。多核平台通过使用不同内核进行不同类型的操作提供优势。

使用 tuna 命令行工具(CLI)，您可以确定缓存布局并将交互线程绑定到内核，以便它们共享缓存。缓存共享通过确保 mutual 排除原语(mutex、条件变量或类似)和数据结构使用相同的缓存来减少内存错误。

现在，许多硬件供应商提供内核与内存之间的透明互连网络，称为非统一内存访问(NUMA)架构。

NUMA 是多处理中使用的系统内存设计，内存访问时间取决于处理器的内存位置。使用 NUMA 时，处理器可以比非本地内存更快地访问自己的本地内存，如处理器之间共享的其他处理器或内存的内存。在 NUMA 系统上，了解互连拓扑有助于将经常在相邻内核中通信的线程放置。

taskset 和 numactl 实用程序决定了 CPU 拓扑。taskset 定义没有 NUMA 资源的 CPU 关联性，如内存节点和 numactl 控制进程和共享内存的 NUMA 策略。

需求分页与页交换的分页系统类似。当需要或 CPU 需求时，系统会加载存储在次要内存中的页面。程序通过处理器中的地址转换机制生成的所有内存地址。然后，地址从特定于进程的虚拟地址转换为物理内存地址。这称为虚拟内存。转换机制中的两个主要组件是页表和翻译查找缓冲区(TLB)

带有分配物理地址的页表条目称为常驻工作集。当操作系统需要为其他进程释放内存时，它可以从常驻工作集中交换页面。在交换页面时，对该页面中的虚拟地址的任何引用都会创建一个页面错误，并导致页面重新分配。

当系统在物理内存上非常低时，交换进程开始为 thrash，从而持续窃取进程中的页面，并且永远不会允许进程完成。您可以通过在 /proc/vmstat 文件中查找 pgfault 值来监控虚拟内存统计信息。

TLB 在引用的本地原则上运行。这意味着，如果代码在大量时间内（如循环或调用相关功能）保留其中一个内存，则 TLB 引用可以避免主内存进行地址转换。这可显著提高处理时间。

在编写确定和快速代码时，请使用维护参考本地功能。这可能意味着使用循环而不是递归。如果递归不可避免，请将递归调用放在函数的末尾。这被称为 tail-recursion，它使代码在相对较小的内存中工作，并避免从主内存调用表转换。

RHEL for Real Time 通过将物理内存分解为名为页面的块来分配内存，然后将它们映射到虚拟内存。当进程需要未映射或在内存中不再可用的特定页面时，会实时发生故障。因此，故障基本上意味着在 CPU 需要时页面不可用。当进程遇到页面错误时，所有线程都会冻结，直到内核处理这个故障为止。解决此问题的方法有多种，但最好的解决方法是调整源代码以避免页面错误。

实时，当应用程序显示性能时，检查 /proc/ 目录中与页面错误相关的进程信息是很有帮助的。对于特定的进程标识符(PID)，您可以使用 cat 命令查看 /proc/PID/stat 文件以了解以下相关条目：

以下示例演示了使用 cat 命令查看页面错误并使用 pipe 功能，只返回 /proc/PID/stat 文件的第二行、第十和第十二行：

cat /proc/3366/stat | cut -d\ -f2,10,12
  (bash) 5389 0

# cat /proc/3366/stat | cut -d\ -f2,10,12
  (bash) 5389 0

在示例输出中，PID 3366 的进程是 bash，它具有 5389 次要页面错误，没有主要页面错误。

内存锁定(mlock （)）系统调用允许调用进程锁定或解锁指定范围的地址空间，并防止 Linux 将锁定的内存分页到交换空间。将物理页面分配给 page 表条目后，对该页面的引用相对较快。内存锁定系统调用属于 mlock （） 和 m unlock （） 类别。

mlock （） 和 m unlock （） 系统调用锁定和解锁指定的进程地址页面。成功后，指定范围内的页面将保持驻留在内存中，直到 m unlock （） 系统调用解锁页面。

mlock （） 和 m unlock （） 系统调用获取以下参数：

成功后，mlock （） 和 m unlock （） 系统调用返回 0。如果出现错误，它们会返回 -1，并设置 errno 来指示错误。

mlockall （） 和 m unlockall （） 系统调用锁定或解锁所有程序空间。

内存锁定会根据页面进行，而不是堆栈。如果两个动态分配的内存片段共享同一页面由 mlock （） 或 mlockall （） 锁定两次，则它们通过使用单个 m lock （） 或 m unlockall （） 系统调用来解锁。因此，务必要了解应用解锁的页面，以避免双锁定或单锁定问题。

以下是缓解双锁定或单锁定问题的两个最常见的临时解决方案：

用于 Real Time 的 RHEL 称为动态共享对象(DSO)，是预编译代码块的集合，称为功能。这些功能可在多个程序中重复使用，它们在运行时或编译时加载。

Linux 支持以下两个库类：

ld.so 动态链路器加载程序所需的共享库，然后执行代码。DSO 函数加载内存中的库一次，然后多个进程可以通过映射到进程的地址空间来引用对象。您可以使用 LD_BIND_NOW 变量将动态库配置为在编译时加载。

在程序初始化前评估符号可以提高性能，因为当内存页面位于外部磁盘上时评估应用程序运行时可能会导致延迟。

在 RHEL for Real Time 中，共享内存是在多个进程间共享的内存空间。通过使用程序线程，在一个进程上下文中创建的所有线程都可以共享相同的地址空间。这使得线程可以访问所有数据结构。使用 POSIX 共享内存调用，您可以配置进程来共享地址空间的一部分。

您可以使用以下支持的 POSIX 共享内存调用：

在实时中，level-signaled 中断使用提供自愿转换的专用中断行。设备控制器通过在中断请求行中模拟信号来引发中断。中断行发送两个 voltages 中的一个来代表二进制 1 或二进制 0。

当中断信号被行发送时，它会一直处于该状态，直到 CPU 重置为止。CPU 执行状态保存、捕获中断并分配中断处理程序。中断处理程序决定了中断的原因，通过执行必要的服务清除中断，并恢复设备的状态。级别签名的中断更为可靠，并且支持多个设备，尽管它们比较复杂。

在实时中，许多系统都使用消息签名中断(MSI)，它将信号发送为数据包或基于消息的电网上的专用消息。这种总线的常见示例是 Peripheral Component Interconnect Express (PCI Express 或 PCIe)。这些设备传输消息类型，PCIe 主机控制器将解析为中断消息。然后，主机控制器会将 上的消息发送到 CPU。

在实时（根据硬件）中，PCIe 系统执行以下操作之一：

在实时中，PCIe 系统还可在传统模式下操作，在实施传统中断行以便支持旧操作系统或引导 Linux 内核时，在内核命令行中使用 pci=nomsi 选项 pci=nomsi。

在实时中，不可屏蔽中断是系统中标准中断的硬件中断无法忽略。NMI 的优先级高于掩码中断。NMI 会出现信号，注意不可恢复的硬件错误。

在实时中，某些系统也使用 NMI 作为硬件监控器。当处理器收到 NMI 时，它通过调用中断向量指向的 NMI 处理程序立即处理 NMI。如果满足某些条件，如在指定时间内没有触发中断，则 NMI 处理程序会发出警告并提供有关问题的调试信息。这有助于识别和阻止系统锁定。

实时中断是硬件中断，通过在中断掩码注册位设置位来忽略这些中断。CPU 可以在关键处理过程中临时忽略可屏蔽中断。

实时，系统管理中断(SMI)提供扩展功能，如传统的硬件设备仿真，也可用于系统管理任务。SMI 与不可屏蔽中断(NMI)类似，它们在使用特殊电脑信号行且通常不可屏蔽。当发生 SMI 时，CPU 会进入系统管理模式(SMM)。在这个模式中，执行特殊的低级处理程序来处理 SMI。SMM 通常直接从系统管理固件提供，通常是 BIOS 或 EFI。

实时 SMI 最常用于提供传统硬件模拟。一个常见的例子是模拟一个 diskette 驱动器。如果没有附加 diskette 驱动器，操作系统会尝试访问 diskette 并触发 SMI。在这种情况下，处理程序会为操作系统提供模拟设备。然后，操作系统会将模拟视为旧设备。

在实时中，SMI 可能会对系统造成负面影响，因为它们无需直接参与操作系统。编写较差的 SMI 处理例程可能会消耗大量 CPU 时间，操作系统可能无法抢占处理程序。这可在其他调优时创建定期高延迟和高度响应的系统。由于供应商可以使用 SMI 处理程序来管理 CPU 温度和 fan 控制，因此可能无法禁用它们。在这种情况下，您必须通知供应商使用这些中断时发生的问题。

在实时中，您可以使用 hwlatdetect 程序隔离 SMI。它包括在 rt-tests 软件包中。这个工具会测量 SMI 处理例程使用 CPU 的时间周期。

Intel 公司开发的高级可编程中断控制器(APIC)提供了以下功能：

实时 APIC 代表一系列设备和技术，它们以可扩展、可管理的方式生成、路由和处理大量硬件中断。它使用在每个系统 CPU 中内置的本地 APIC 的组合以及直接连接到硬件设备的输入/输出 APIC。

在实时时，当硬件设备生成中断时，连接的 I/O APIC 会检测到并路由系统 APIC 总线到特定 CPU 的中断。操作系统知道 IO-APIC 连接到设备，并在该设备中中断行。高级配置和电源接口区分系统描述表(ACPI DSDT)包括有关主机系统主板和外围组件的特定 wiring 的信息，以及设备提供有关可用中断源的信息。这两个数据集合一起提供有关总体中断层次结构的信息。

RHEL for Real Time 支持使用层次结构中连接的系统 APIC 基于 APIC 的中断管理策略，并通过负载均衡的方式向 CPU 提供中断，而不是针对特定 CPU 或一组 CPU。

实时进程在最简单的方面是执行中的程序。术语进程指的是独立地址空间，可能包含多个线程。当开发了多个进程在一个地址空间内运行时，Linux 转而成一个与其他进程共享地址空间的进程结构。只要进程数据结构很小，就可以正常工作。

UNIX® 风格的进程结构包含：

实时中，每个进程通过一个线程启动，通常称为父线程。您可以使用 fork （） 系统调用从父线程创建额外的线程。fork （） 创建新的子进程，与父进程相同，但新进程标识符除外。子进程独立于创建进程运行。可以同时执行父进程和子进程。fork （） 和 exec （） 系统调用之间的区别在于，fork （） 启动一个新进程，它是父进程的副本，exec （） 将当前进程替换为新进程镜像。

在实时中，fork （） 系统调用在成功时返回子进程的进程标识符，父进程返回非零值。出错时，它会返回错误号。

在实时中，进程中可以存在多个线程。进程的所有线程共享其虚拟地址空间和系统资源。线程是一个可调度的实体，包含：

在实时中，以下是创建并行性的潜在机制：

在对实时线程进行分叉前，您必须评估组件交互级别。当组件独立于另一个或较少交互时，创建新的地址空间并将其作为新进程运行是有益的。当组件需要共享数据或经常通信时，在一个地址空间中运行线程会更高效。

实时中，fork （） 系统调用在成功时返回零值。出错时，它会返回错误号。

在多处理器系统中发现的多个时钟源实例，如非统一内存访问(NUMA)和 Symmetric 多处理(SMP)，并在自身间交互，以及它们对系统事件的响应方式，如 CPU 频率扩展或进入能源经济模式，确定它们是否适合实时内核的时钟源。

首选时钟源是时间戳计数器(TSC)。如果 TSC 不可用，则 Highrecision Event Timer (HPET)是第二个最佳选项。但是，并非所有系统都有 HPET 时钟，一些 HPET 时钟可能不可靠。

如果没有 TSC 和 HPET，其他选项包括 ACPI Power Management Timer (ACPI_PM)、Programmable Interval Timer (PIT)和 Real Time Clock (RTC)。最后两个选项需要昂贵，读取或具有低分辨率（时间粒度），因此它们是与实时内核一起使用的子选择。

POSIX 是实施和代表时间源的标准。您可以将 POSIX 时钟分配给应用程序，而不影响系统中的其他应用程序。这与内核选择并在系统中实施的硬件时钟不同。

用于读取给定 POSIX 时钟的功能是 clock_gettime （），它在 < time.h > 定义。内核与 clock_gettime （） 是系统调用。当用户进程调用 clock_gettime （） 时：

但是，从用户应用程序切换到内核的上下文会有 CPU 成本。尽管这种成本非常低，如果操作重复了数以千计的时间，但累计成本可能会对应用程序的整体性能产生影响。为了避免上下文切换到内核，从而可以更快地读取时钟，支持 CLOCK_MONOTONIC_COARSE 和 CLOCK_REALTIME_COARSE POSIX 时钟，格式为虚拟动态共享对象(VDSO)库功能。

使用其中一个 _COARSE 时钟变体执行 clock_gettime （） 执行的时间读取，不需要内核干预，完全在用户空间中执行。这带来了显著的性能提升。读取 _COARSE 时钟的时间读取具有毫秒(ms)解析，这意味着不会记录时间间隔小于 1 ms。POSIX 时钟的 _COARSE 变体适合可容纳数毫秒时钟解析的任何应用程序。

以下代码演示了使用带有 CLOCK_MONOTONIC_COARSE POSIX 时钟的 clock_gettime （） 函数的代码示例：

#include <time.h>
main()
{
	int rc;
	long i;
	struct timespec ts;

	for(i=0; i<10000000; i++) {
		rc = clock_gettime(CLOCK_MONOTONIC_COARSE, &ts);
	}
}

#include <time.h>
main()
{
	int rc;
	long i;
	struct timespec ts;

	for(i=0; i<10000000; i++) {
		rc = clock_gettime(CLOCK_MONOTONIC_COARSE, &ts);
	}
}

您可以改进上面的示例，添加检查来验证 clock_gettime() 的返回值，验证 rc 变量的值，或确保 ts 结构的内容被信任。

实时线程的优先级高于标准线程。策略具有调度优先级值，范围从最小值 1 到最大值 99。

以下策略对实时至关重要：

每个 SCHED_DEADLINE 任务都按 句点、运行时和 截止时间 参数表示。这些参数的值是纳秒的整数。

Red Hat Enterprise Linux 中的 sched_deadline_period_max_us 和 sched_deadline_period_min_us 参数是 SCHED_DEADLINE 调度策略的内核可调参数。这些参数通过使用此实时调度类来控制任务的最大允许周期（以微秒为单位）。

sched_deadline_period_max_us 和 sched_deadline_period_min_us 一起工作，为 SCHED_DEADLINE 任务的 period 值定义一个可接受的范围。

参数的值以微秒为单位。例如，1 秒等于 100000 微秒。

默认情况下，进程可以实时运行任意 CPU。但是，您可以通过更改进程的关联性，将进程配置为在预先确定的 CPU 上运行。子进程继承其父进程的 CPU 相关性。

在系统中调优操作的实际情况是确定运行应用程序所需的内核数量，然后隔离这些内核。这可以通过 Tuna 工具来实现，也可以使用 shell 脚本修改位掩码值。

taskset 命令可用于更改进程的关联性，并修改 /proc/ filesystem 条目会更改中断的关联性。使用带有 -p 或 --pid 选项的 taskset 命令和进程的进程标识符(PID)检查进程的关联性。

-c 或 --cpu-list 选项显示内核的数字列表，而不是位掩码。可以通过指定要绑定特定进程的 CPU 数量来设置关联性。例如，对于之前使用 CPU 0 或 CPU 1 的进程，您可以更改关联性，使其只能在 CPU 1 上运行。除了 taskset 命令外，您还可以使用 sched_setaffinity （） 系统调用来设置处理器关联性。

内核的截止时间调度类(SCHED_DEADLINE)在截止时间前实施第一次调度程序(EDF)，用于有有限期限的任务。它根据作业截止时间排列任务优先级：最早的绝对截止时间。除了 EDF 调度程序外，截止时间调度程序也实现了恒定的带宽服务器(CBS)。CBS 算法是一个资源保留协议。

CBS 确保每个任务在每个期间 (T) 接收其运行时间 (Q)。在任务的每个激活开始时，CBS 重新配置任务的运行时。在作业运行时，它会消耗其 运行时，如果任务超出 运行时，则任务会节流和取消调度。节流机制可防止单个任务运行超过其运行时，并有助于避免其他作业的性能问题。

实时，为了避免在 截止时间 任务的情况下过载系统，截止时间调度程序 会实施验收测试，每次任务被配置为 使用截止时间调度程序 运行时运行。接受的测试保证了 SCHED_DEADLINE 任务不使用超过 kernel.sched_rt_runtime_us/kernel.sched_rt_period_us 文件（默认为 950 ms 超过 1s）的 CPU 时间。

mutex 从 mutual 排除术语衍生而来。mutual exclude 对象同步对资源的访问。它是确保一个线程一次只能获取 mutex 的机制。

mutex 算法创建对每个代码的每个部分的串行访问，因此在任何时间点上只能有一个线程执行代码。Mutexes 使用称为 mutex 属性对象的属性对象来创建。这是一个抽象对象，其中包含几个依赖于您选择的 POSIX 选项的属性。attribute 对象通过 pthread_mutex_t 变量定义。对象存储为 mutex 定义的属性。pthread_mutex_init (&my_mutex, &my_mutex_attr), pthread_mutexattr_setrobust （） 和 pthread_mutexattr_getrobust （） 功能返回 0。出错时，它们会返回错误号。

在实时中，您可以保留属性对象来初始化同一类型的更多 mutexes，也可以清理(destroy)属性对象。mutex 在任一情况下都不受影响。Mutexes 包括标准和高级 mutexes。

在手动释放之前，非robust mutex 不会自动发布并保持锁定状态。

与其他线程同步方法相比，障碍以非常不同的方式运行。障碍定义代码中所有活动线程停止的点，直到所有线程和进程达到这一障碍为止。当运行的应用程序需要确保所有线程都已完成特定任务时，可以使用障碍，然后再执行才可以继续。

barrier mutex 实时使用以下两个变量：

只有指定数量的线程数量达到定义的 barrier 时，barrier 才会将状态设置为 pass。当 barrier 状态设置为 通过 时，线程和进程将继续进行。pthread_barrier_init （） 函数分配所需的资源以使用定义的 barrier 并使用 attr 属性对象引用的属性进行初始化。

当成功时，pthread_barrier_init （） 和 pthread_barrier_destroy （） 函数返回零值。出错时，它们会返回错误号。

在实时中，条件变量(condvar)是一个 POSIX 线程构造，在继续前等待执行特定条件。通常，信号条件与线程与其他线程共享的数据状态相关。例如，condvar 可用于向处理队列发送数据条目，以及等待队列中处理该数据的线程。使用 pthread_cond_init （） 函数，您可以初始化条件变量。

当成功时，pthread_cond_init （）、pthread_cond_wait （） 和 pthread_cond_signal （） 函数返回零值。出错时，它会返回错误号。

上述 mutex 选项提供了在编写或移植应用程序时需要考虑的 mutex 类的指导。

上述功能类型列表和描述提供了用于实时内核线程同步机制的功能信息。

TCP_NODELAY 套接字选项禁用 Nagle 的算法。使用 setsockopt socket API 功能配置 TCP_NODELAY，当单个数据包就绪后立即发送多个小缓冲区写入。

在发送之前，通过构建连续数据包以单一数据包的形式发送多个逻辑相关的缓冲区，以实现更好的延迟和性能。或者，如果内存缓冲区是逻辑上相关但不是连续的，您可以在启用了 TCP_NODELAY 的套接字中使用 writev 创建 I/O 向量，并将其传递给内核。

以下示例演示了通过 setsockopt socket API 启用 TCP_NODELAY。

int one = 1;
setsockopt(descriptor, SOL_TCP, TCP_NODELAY, &one, sizeof(one));

int one = 1;
setsockopt(descriptor, SOL_TCP, TCP_NODELAY, &one, sizeof(one));

TCP_CORK 选项收集套接字中的所有数据包，并阻止传输它们，直到缓冲区填充到指定的限制。这使得应用能够在内核空间中构建数据包，并在禁用 TCP_CORK 时发送数据。使用 setsocketopt （） 函数在套接字文件描述符上设置 TCP_CORK。在开发程序时，如果必须从文件发送批量数据，请考虑使用带有 sendfile （） 函数的 TCP_CORK。

当通过各种组件在内核中构建逻辑数据包时，可使用 setsockopt 套接字 API 将它配置为 1 的值来启用 TCP_CORK。这称为 "corking the socket"。如果特定时间没有删除 cork，TCP_CORK 可能会导致错误。

以下示例演示了通过 setsockopt socket API 启用 TCP_CORK。

int one = 1;
setsockopt(descriptor, SOL_TCP, TCP_CORK, &one, sizeof(one));

int one = 1;
setsockopt(descriptor, SOL_TCP, TCP_CORK, &one, sizeof(one));

在某些环境中，如果内核无法识别何时删除 cork，您可以手动删除它，如下所示：

int zero = 0;
setsockopt(descriptor, SOL_TCP, TCP_CORK, &zero, sizeof(zero));

int zero = 0;
setsockopt(descriptor, SOL_TCP, TCP_CORK, &zero, sizeof(zero));

TCP_NODELAY 和 TCP_CORK 套接字选项可显著影响网络连接的行为。TCP_NODELAY 在应用程序上禁用 Nagle 的算法，该算法在应用程序就绪后马上发送数据包。使用 TCP_CORK，您可以同时传输多个数据数据包，而在它们之间没有延迟。

gcc tcp_nodelay_client.c -o tcp_nodelay_client -lrt

gcc tcp_nodelay_client.c -o tcp_nodelay_client -lrt

示例程序提供有关这些套接字选项对应用程序的性能影响的信息。

以下示例使用回环接口来演示三种变体：

chrt 实用程序检查并调整调度程序策略和优先级。它可以启动具有所需属性的新进程，或更改正在运行的进程的当前属性。

chrt 实用程序使用 --pid 或 -p 选项指定进程 ID (PID)。

chrt 工具采用以下策略选项：

以下示例显示了指定进程的属性。

chrt -p 468

# chrt -p 468
pid 468’s current scheduling policy: SCHED_FIFO
pid 468’s current scheduling priority: 85

实时抢占是一种临时中断执行任务的机制，希望稍后恢复它。当优先级较高的进程中断 CPU 用量时，会发生它。抢占可能会对性能造成负面影响，持续的抢占可导致名为"垃圾箱"的状态。当进程不断抢占且任何进程需要完全运行时，会出现这个问题。更改任务的优先级可帮助减少非自愿抢占。

您可以通过查看 /proc/PID/status 文件的内容（其中 PID 是进程标识符），检查单个进程上发生的 voluntary 和 involuntary 抢占。

以下示例显示了 PID 为 1000 的进程的抢占状态。

grep voluntary /proc/1000/status

# grep voluntary /proc/1000/status
voluntary_ctxt_switches: 194529
nonvoluntary_ctxt_switches: 195338

实时进程使用一组不同的库调用来控制策略和优先级。功能需要包含 sched.h 标头文件。符合 SCHED_OTHER, SCHED_RR 和 SCHED_FIFO 也需要在 sched.h header 文件中定义。

表列出了为实时调度程序设置策略和优先级的功能。

sched_yield （） 函数是为处理器选择运行进程以外的进程。从不编写的应用程序内发布，这种类型的请求容易失败。

当在具有实时优先级的进程中使用 sched_yield （） 函数时，它可能会显示意外行为。调用 sched_yield （） 的进程将移到以相同优先级运行的进程队列的尾部。如果没有以同样优先级运行其他进程，名为 sched_yield （） 的进程将继续运行。如果该进程的优先级较高，它可能会创建一个忙碌循环，从而导致机器不可用。

通常，不要在实时进程中使用 sched_yield （）。

getrusage （） 函数从指定的进程或其线程中检索重要信息。它报告以下信息，例如：

Getrusage （） 允许您查询应用程序，以提供与性能调优和调试活动相关的信息。Getrusage （） 检索需要从 /proc/ 目录中的几个不同文件目录的信息，并难以与应用程序上的特定操作或事件同步。

实时调度策略共享一个主要特征：它们运行，直到优先级更高的线程中断线程或线程等待，或者通过睡眠或执行 I/O 来中断线程。

对于 SCHED_RR，操作系统会中断正在运行的线程，以便运行相等的 SCHED_RR 优先级的另一个线程。在这两种情形中，POSIX 规范不会进行调配，以定义允许低优先级线程获得任何 CPU 时间的策略。这种实时线程的特征意味着可轻松编写一个应用程序，这会使给定 CPU 的 100% 保持了。但是，这会导致操作系统出现问题。例如，操作系统负责管理系统范围和每个 CPU 资源，必须定期检查描述这些资源的数据结构，并执行日常活动。但是，如果某个内核由 SCHED_FIFO 线程进行单调，则无法执行其内务任务。最终，整个系统变得不稳定，并可能导致崩溃。

在 RHEL for Real Time 内核中，中断处理程序作为具有 SCHED_FIFO 优先级的线程运行。默认优先级为 50。具有 SCHED_FIFO 或 SCHED_RR 策略高于中断处理器线程的 cpu-hog 线程可防止中断处理程序运行。这会导致程序等待这些中断信号的数据失败，并失败。

实时内核包含一个保护机制，它允许分配供实时任务使用的带宽。保护机制被称为实时调度程序节流。

实时节流机制的默认值定义实时任务可以使用 95% 的 CPU 时间。其余的 5% 将被视为非实时任务，例如在 SCHED_OTHER 和类似调度策略下运行的任务。务必要注意，如果单个实时任务占据了 95% 的 CPU 时间插槽，则该 CPU 上的剩余实时任务将不会运行。只有非实时任务会使用剩余的 CPU 时间的 5%。默认值可能会有以下性能影响：

实时调度程序节流由 /proc 文件系统的以下参数控制：

当线程位于 CPU 运行队列中超过 starvation 阈值且不会进行进度时，线程不足发生。线程不足的常见原因是运行固定优先级轮询应用，如 SCHED_FIFO 或绑定到 CPU 的 SCHED_RR。由于轮询应用不阻止 I/O，因此这可以防止其他线程（如 kworkers ）在那个 CPU 上运行。

早期尝试减少线程星化会作为实时节流调用。在实时节流中，每个 CPU 具有一部分执行时间，专用于非实时任务。节流的默认设置是 95% 的 CPU，用于实时任务，为非实时任务保留 5%。如果您有单个实时任务导致出现不足的情况，则这可以正常工作，但如果分配给 CPU 有多个实时任务，则无法正常工作。您可以使用以下方法解决这个问题：