了解 RHEL for Real Time

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

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

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

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

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

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

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

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

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

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

TLB 根据引用的本地原则进行操作。这意味着，如果代码在一段时间内处于一个内存中（如循环或调用相关的功能），则 TLB 引用避免了地址转换的主要内存。这可显著加快处理时间。

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

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

在实时，当应用程序显示性能丢弃时，检查 /proc/ 目录中页面错误的进程信息会很有帮助。对于使用 cat 命令的特定进程标识符(PID)，您可以查看以下相关条目的 /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 分页锁定的内存以交换空间。将物理页面分配给页表条目后，对该页的引用相对快。内存锁定系统调用属于 mlock （） 和 munlock （） 类别。

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

mlock （） 和 munlock （） 系统调用采用以下参数：

成功时，mlock （） 和 munlock （） 系统调用返回 0。如果出现错误，则返回 -1 并设置 errno 来指示错误。

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

内存锁定是以页为基础进行的，不堆栈。如果两个动态分配的内存片段通过 mlock （） 或 mlockall （） 共享同一页面，它们通过使用单个 munlock （） 或 munlockall （） 系统调用来解锁。因此，务必要了解应用程序解锁的页面，以避免出现双锁或单解锁问题。

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

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

Linux 支持以下两个库类：

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

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

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

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

浮点单元是处理器的功能部分，其执行浮点算术操作。浮点单元处理数学操作，使浮动数或十进制计算变得更加简单。

使用-- matrix-method 选项，您可以压力测试 CPU 浮动点操作和处理器数据缓存。

stress-ng 工具运行多个压力测试。在默认模式中，它会并行运行指定的压力器机制。

为了测量 CPU 热代，指定的压力函数在短时间内生成高温度，以测试系统在最热生成之下的冷却可靠性和稳定性。使用-- matrix-size 选项，您可以在短时间内测量 Celsius 的 CPU 温度。

stress-ng 工具可以通过测量每秒 bogo 操作来测量压力测试吞吐量。bogo 操作的大小取决于运行的压力。测试结果不是精确的，但提供了性能粗略估算。

您不能将此测量用作准确的基准指标。这些估计结果有助于了解不同内核版本或用于构建 stress-ng 的不同编译器版本中的系统性能变化。使用 --metrics-brief 选项显示可用 bogo 操作总数以及机器上的矩阵压力器性能。

在内存压力下，内核开始写出页面到交换。您可以使用 -page-in 选项强制非常数页面 交换回虚拟内存，对虚拟内存进行压力测试。这会导致虚拟机被大量练习。使用 --page-in 选项，您可以为 bigheap、mmap 和虚拟机(vm)压力启用此模式。page-in 选项，touch 分配不在核心的页面，强制它们进入页面。

以高频率运行计时器可生成大型中断负载。带有适当所选计时器频率的-- timer 压力可能会强制每秒有多个中断。

使用 stress-ng 时，您可以通过在内存中未加载的页面中生成主要页面错误来测试和分析页面错误率。在新内核版本中，用户faultfd 机制会通知错误查找进程虚拟内存布局中的页面错误。

CPU 压力测试包含执行 CPU 的方法。您可以使用哪个选项打印输出来查看所有方法。

如果您没有指定测试方法，默认情况下，压力会以轮循方式检查所有压力，以测试每个压力者的 CPU。

当测试处于活跃状态时，验证模式会验证结果。它将检查测试运行中的内存内容，并报告任何意外故障。

由于在这个模式下运行的额外验证步骤，所有压力者都没有验证模式，并且启用将减少 bogo 操作统计信息。

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

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

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

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

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

在实时，不可屏蔽的中断是系统中标准中断屏蔽技术的硬件中断。NMI 的优先级高于可屏蔽中断。发生 NMI 来表示不可恢复的硬件错误。

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

在实时，可屏蔽中断是通过在中断掩码寄存器的位掩码中设置位来忽略的硬件中断。CPU 可以在关键处理过程中临时忽略可屏蔽的中断。

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

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

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

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

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

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

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

RHEL for Real Time 支持基于 Complex APIC 的中断管理策略，并在层次结构中连接系统 APIC，并以负载均衡方式向 CPU 提供中断，而不是以特定的 CPU 或一组 CPU 为目标。

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

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

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

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

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

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

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

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

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

首选时钟源是时间戳计数器(TSC)。如果 TSC 不可用，则高精度事件时间(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 变体适合可容纳 millisecond 时钟分辨率的任何应用程序。

以下代码显示了使用带有 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 微秒。

运行时验证(RV)监控器封装在 RV 监控抽象中，并在定义的规格和内核追踪之间协调，以在 trace 文件中捕获运行时事件。RV 监控器包括：

除了在运行时验证和监控系统外，您还可以启用对意外系统事件的响应。反应形式的反应可能与在 trace 文件中捕获事件不同，以启动非常反应，如关闭，以避免在安全关键系统上出现系统故障。

Reactors 是 RV 监视器可用的反应方法，根据需要定义对系统事件的反应。默认情况下，监控器提供操作的追踪输出。

运行时验证(RV)监控器分为以下类型：

用户界面位于 /sys/kernel/tracing/rv，类似于追踪接口。用户界面包含上述文件和文件夹。

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

在系统上调优关联性的实时做法是确定运行应用程序所需的内核数，然后隔离这些内核。这可以通过 Tuna 工具或 shell 脚本修改 bitmask 值来实现。

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

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

内核截止时间调度类(SCHED_DEADLINE)为具有受限期限的 sporadic 任务实施早期期限第一个调度程序(EDF)。它根据作业截止时间对任务进行优先排序：首先最早的绝对期限。除了 EDF 调度程序外，截止时间调度程序还实施恒定带宽服务器(CBS)。CBS 算法是一个资源保留协议。

CBS 保证每个任务在每个期间 (T) 接收其运行时 (Q)。每次激活一个任务时，CBS 会清除任务的运行时间。当作业运行时，它会消耗其 运行时，如果任务没有运行时，则任务会节流和取消调度。节流机制可防止单个任务运行超过其运行时，有助于避免其他作业的性能问题。

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

Mutex 从相互排除的术语中派生出来。mutual exclude 对象同步对资源的访问。它是保证一个线程一次只能获取 mutex 的机制。

mutex 算法会创建一个对代码的每个部分的串行访问，以便在任何时候都执行代码。mutex 使用称为 mutex 属性对象的属性对象创建。这是一个抽象对象，其中包含多个取决于您选择实现的 POSIX 选项的属性。属性对象通过 pthread_mutex_t 变量定义。对象存储为 mutex 定义的属性。pthread_mutex_init (&my_mutex, &my_mutex_attr), pthread_mutexattr_setrobust （） 和 pthread_mutexattr_getrobust （） 函数返回 0。出错时，它们会返回错误号。

在实时中，您可以保留属性对象来初始化同一类型的更多静默，或者您可以清理（销毁）属性对象。mutex 在这两种情况下都不会受到影响。mutexes 包括标准和高级 mutexes。

非滥用 mutex 不会自动发布并保持锁定，直到手动释放为止。

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

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

只有指定数量的线程数量达到定义的 barrier 时，barrier 才会将状态设置为 pass。当 barrier 状态设置为 pass 时，线程和进程将继续。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 会在单个数据包就绪后立即发送多个小缓冲区写入。

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

以下示例演示了通过 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 socket 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 工具使用 either-- pid 或 the -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 用量时，会发生它。抢占可能会对性能有负面影响，持续抢占可能会导致状态称为 thrashing。当进程被持续抢占且没有完全运行任何进程时，会出现这个问题。更改任务的优先级有助于减少非自愿抢占。

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

以下示例显示了 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/ 目录中的多个不同文件进行目录，并难以与应用程序上的特定操作或事件同步。

您可以通过在追踪系统的 curret_tracer 文件中添加 timerlat 来配置 timerlat 追踪器。current_tracer 文件通常挂载到 /sys/kernel/tracing 目录中。timerlat 追踪器测量中断请求(IRQ)，并在线程延迟超过 100 微秒时保存用于分析的 trace 输出。

timerlat 追踪器基于 osnoise tracer 构建。因此，您可以将 /osnoise/config 目录中的选项设置为 trace 并捕获线程调度延迟的信息。

rtla-timerlat-top tracer 显示 timerlat tracer 中定期输出的摘要。tracer 输出还提供有关每个操作系统声明和事件的信息，如 osnoise 和 追踪点。您可以使用 the -t 选项查看此信息。

通过使用 rtla timerlat top --help 命令，您可以查看 rtla-timerlat-top tracer 选项的帮助用法。

Linux 内核包含实时分析(rtla)工具，它为操作系统 noise (osnoise) tracer 提供了一个接口。rtla-osnoise tracer 创建一个在指定时间段内定期运行的线程。在 句点 开始时，线程会禁用中断，启动抽样，并在循环中捕获时间。

rtla-osnoise tracer 提供以下功能：

rtla-osnoise tracer 会打印一个运行报告，并在周期的结论中提供有关 noise 源的以下信息：

您可以通过在追踪系统的 curret_tracer 文件中添加 osnoise 来配置 rtla-osnoise tracer。current_tracer 文件通常挂载到 /sys/kernel/tracing/ 目录中。rtla-osnoise 追踪器测量中断请求(IRQ)，并在线程延迟超过 20 微秒内保存分析的 trace 输出。

rtla-osnoise tracer 的配置选项位于 /sys/kernel/tracing/ 目录中。

rtla-osnoise 包括一组用来识别操作系统发行源的 追踪点 (osnoise)。

osnoise/options 文件包括一组用于 rtla-osnoise tracer 的配置选项。

rtla osnoise-top tracer 测量并显示 osnoise tracer 的定期摘要，以及有关 interference 源发生计数器的信息。

通过使用 rtla osnoise top --help 命令，您可以查看 rtla-osnoise-top tracer 可用选项的帮助用法。

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

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

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

实时内核包含一个保护机制，用于启用分配给实时任务使用的带宽。保护机制称为实时调度程序节流。

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

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

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

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