是什么让内核/操作系统实时？

Question

我正在阅读这篇文章,但我的问题是在一个通用的层面,我正在考虑以下几点:

1. 内核可以实时调用,因为它有实时调度程序吗？或者换句话说,假设我有一个Linux内核,如果我将默认调度程序从O(1)或更改CFS为a real time scheduler,它是否会成为RTOS？
2. 它需要硬件的任何支持吗？通常我看到嵌入式设备有RTOS(例如VxWorks,QNX),这些有没有特殊规定/ hw来支持它们？我知道RTOS进程的运行时间是确定性的,但是可以使用longjump/setjump在确定的时间内获得输出.

我真的很感激它的一些输入/见解,如果我对某事有误,请纠正我.

Answer 1

在做了一些研究之后,与人们交谈(Jamie Hanrahan,Juha Aaltonen @linkedIn Group - 设备驱动专家)以及@Jim Garrison的输入,我可以得出结论:

在Jamie Hanrahan的话中 -

是什么让内核实时？
的必要条件实时操作系统-

• 能够保证外部中断和中断处理程序启动之间的最大延迟.

  请注意,最大延迟不需要特别短(例如微秒),您可以拥有一个实时操作系统,保证绝对最大延迟为137毫秒.

• 实时调度程序是一个为线程调度提供完全可预测(对开发人员)行为的调度程序 - "下一个运行的线程".

  这通常与保证响应中断的最大延迟的问题是分开的(因为中断处理程序不一定像普通线程一样进行调度),但通常需要实现实时应用程序.实时操作系统中的调度程序通常实现大量优先级.并且它们几乎总是实现优先级继承,以避免优先级反转情况.

因此,保证中断的延迟和线程调度的可预测性是好的,那么为什么不让每个操作系统都实时？

• 因为适合于通用目的的OS(服务器和/或桌面)需要具有通常与实时延迟保证不一致的特性.

  例如,实时调度程序应具有完全可预测的行为.这意味着,除了其他事项之外,开发人员为各种任务分配的优先级应由操作系统单独留下.这可能意味着一些低优先级的任务最终会长时间处于饥饿状态.但RT操作系统不得不耸耸肩说"这就是开发人员想要的东西".请注意,以获得正确的行为,在RT系统开发人员担心很多这样的事情的任务优先级和CPU亲和力.

  通用操作系统正好相反.您希望能够在其上抛出应用程序和服务,几乎总是由许多不同供应商编写的东西(而不是像大多数RT系统那样紧密集成的系统),并获得良好的性能.也许不是绝对最好的表现,但好.

  请注意,"良好性能"不仅仅是在中断延迟中测量的.特别是,您希望CPU和其他资源分配通常被描述为"公平",没有用户或管理员,甚至应用程序开发人员不必担心线程优先级和CPU关联性和NUMA节点等问题.一项工作可能比另一项工作更重要,但在通用操作系统中,这并不意味着第二项工作根本就没有资源.

  因此,通用操作系统通常会在相同优先级的线程之间实现时间分片,并且可以根据其过去的行为调整线程的优先级(例如,CPU hog可能优先级降低; I/O绑定线程可能具有其优先级优先级增加,因此它可以保持I/O设备正常工作; CPU缺乏的线程可能会提升其优先级,因此它可以获得一点CPU时间.

内核可以实时调用,因为它有实时调度程序吗？

• 不,RT调度程序是RT OS的必要组件,但您还需要在OS的其他部分中进行可预测的行为.

它需要硬件的任何支持吗？

• 通常,硬件越简单,其行为就越可预测.所以PCI-E比PCI更难以预测,而PCI的可预测性要低于ISA等.有一些特定的I/O总线设计用于(例如)中断延迟的简单可预测性,但很多RT要求都可以这些天用商品硬件来满足.

Answer 2

实时的具体描述是进程有最小响应时间保证。这对于应用程序来说通常是不够的，甚至不如决定论那么重要。对于现代功能丰富的操作系统来说，这是尤其难以实现的。考虑：

如果我想在精确的时间点命令某些硬件或机器，我需要能够在这些特定时刻生成命令信号，通常具有远亚毫秒的精度。一般来说，如果你编译一个 C 代码，它运行一个等待“半毫秒”的循环并执行某些操作，则等待时间并不完全是半毫秒，而是多一点，因为常见操作系统处理此问题的方式，是他们至少把进程放在一边，直到正确的时间过去，之后调度程序可能（在某个时刻）再次拿起它。

严重的问题不在于时间 t 不正好是半秒，而是无法提前知道它到底多了多少。这种不准确性不是恒定的也不是确定性的。

在进行物理自动化时，这会产生令人惊讶的后果。例如，如果不通过内核接口使用专用硬件并告诉它们您真正想要多长的时间步长，则不可能使用任何典型的操作系统准确地命令步进电机。因此，单个 AVR 模块可以准确地控制多个电机，但 Raspberry Pi（在时钟速度方面绝对超越 AVR）无法使用任何典型操作系统管理超过 2 个电机。