四、x86 Linux 系统的调度策略

我们日常使用的 PC 机,它的主要目标是并行执行多任务,强调的是吞吐率(尽可能多的执行很多应用程序的代码),因此,采用的是分时操作系统,也就是每个任务都有一个时间片,当一个任务分配的时间片用完了,就自动换出(调度),然后执行下一个任务。

我们平常在写 x86 平台上写普通的客户端程序时,很少需要指定应用程序的调度策略和优先级,使用的是系统默认的调度机制。反过来说,也就是在某些需要的场合下,是可以设置进程的调度策略和优先级的。

例如在 Linux 系统中,可以通过 sched_setscheduler() 系统函数 设置 3 种调度策略:

1． SCHED_OTHER: 系统默认的调度策略,计算动态优先级(counter+20-nice),当时间片用完之后放在就绪队列尾;

2． SCHED_FIFO: 实时调度策略,根据优先级进行调度,一旦占用CPU就一直执行,直到自己放弃执行或者有更高优先级的任务需要执行;

3． SCHED_RR: 也是实时调度策略,在 SCHED_FIFO 的基础上添加了时间片。在执行时,可以被更高优先级的任务打断,如果没有更高优先级的任务,那么当任务的执行时间片用完之后,就会查找相同优先级的任务来执行。

1． 为什么 Linux 系统是软实时的?

可能有小伙伴会有疑问:既然 Linux 系统中提供了 SCHED_FIFO 基于优先级的调度策略,为什么仍然不能称之为真正的硬实时操作系统?这就要从 Linux 的发展历史说起了。

Linux 操作系统在设计之初,就是为了桌面应用而开发的,在那个时代,多个终端(电传打字机和屏幕)连接到同一个电脑主机,需要处理的是多任务、并行操作,并不需要考虑实时性,因此,在 Linux 内核中的一些基因,严重影响了它的实时性,例如有如下几个因素:

(1) 内核不可抢占

我们知道,一个应用程序在执行时,可以在用户态和内核态执行(当调用一个系统函数,例如:write 时,就会进入内核态执行),此时任务是不可抢占的。

即使有优先级更高的任务准备就绪,当前的任务也不能立刻停止执行。而是必须等到当前这个任务返回到用户态,或者在内核态中需要等待某个资源而睡眠时,高优先级任务才可以执行。

因此,这就很显然无法保证高优先级任务的实时性了。

(2) 自旋锁

自旋锁是用于多线程同步的一种锁,用来对共享资源的一种同步机制,线程反复检查锁变量是否可用。由于线程在这一过程中保持执行,因此是一种忙等待。一旦获取了自旋锁,线程会一直保持该锁,直至显式释放自旋锁。

自旋锁避免了进程上下文的调度开销,因此对于线程只会阻塞很短时间的场合是有效的,也就是说,只能在阻塞很短的时间才适合使用自旋锁。

但是,在自旋锁期间,任务抢占将会失效,这就是说,即使自旋锁的阻塞时间很短,但是这仍然会增加任务抢占延时,让调度变得不确定。

(3) 中断的优先级是最高的

任何时刻,只要中断发生,就会立刻执行中断服务程序,也就是中断的优先级是最高的。只有当所有的外部中断和软终端都处理结束了,正常的任务才能得到执行。

这看起来是好事情,但是想一想,如果有比中断优先级更高的任务呢?假如系统在运行中,网口持续接收到数据,那么中断就一直被执行,那么其他任务就可能一直得不到执行的机会,这是影响 Linux 系统实时性的巨大挑战。

(4) 同步操作时关闭中断

如果去看 Linux 内核的代码,可以看到在很多地方都执行了关中断指令,如果在这期间发生了中断,那么中断响应时间就没法保证了。

2． Linux 系统如何改成硬实时?

以上描述的几个因素,对 Linux 实现真正的实时性构成了很大的障碍,但是现实世界又的确有很多场合需要 Linux 具有硬实时,那么就要针对上面的每一个因素提出解决方案。

目前主流的解决方案有 2 个:

单内核解决方案:给 Linux 内核打补丁,解决上面提到的几个问题,例如:RT-Preempt;双内核解决方案:在硬件抽象层之上,运行 2 个内核:实时内核 + Linux 内核,它们分别向上层提供 API 函数,例如:Xenomai;

这 2 种解决方案分别有不同的实现,从调研情况来看,RT-Preempt 和 Xenomai 是使用比较多的,下面分别来看一下他们的优缺点。

(1)RT-Preempt

这种方式主要是对 Linux 内核进行打补丁,解决了上面所说的几个问题:内核不可抢占、自旋锁、关中断以及终端优先级的问题。

至于每一个问题是如何解决的,由于篇幅关系,这里就不介绍了,感兴趣的小伙伴如果需要的话,可以深入了解一下。

由于是直接在 Linux 内核上打补丁(以后肯定会合并到主分支中的),因此对于应用程序开发来说,操作系统向上层提供的 API 接口函数可以保持不变,这对应用程序开发来说是一件好事情。