Real-Time进程会导致系统lockup吗
Linux kernel支持两种实时(real-time)调度策略(scheduling policy)：SCHED_FIFO和SCHED_RR，无论是哪一种，实时进程的优先级范围[0~99]都高于普通进程[100~139]，始终优先于普通进程得到运行。如果实时进程是CPU消耗型的，会不会导致其它进程得不到运行机会，造成系统lockup呢？
这实际上是两个问题，不能混为一谈，第一个问题是会不会造成系统lockup，第二个问题是会不会导致其它进程得不到运行机会。我们一个一个分别来谈。
实时进程会不会造成系统lockup？
Lockup分为soft lockup和hard lockup，我在《内核如何检测soft lockup与hard lockup》一文中解释了Linux kernel检测lockup的原理，参见http://linuxperf.com/?p=83。
Hard lockup发生在CPU中断被屏蔽的情况下，因为实时进程本身并不会屏蔽CPU中断，hrtimer时钟中断是可以得到响应的，所以不会导致hard lockup。
Soft lockup发生在内核线程[watchdog/x]得不到运行的情况下，理论上如果实时进程占着CPU不放，确实有可能导致[watchdog/x]得不到运行而发生soft lockup，然而这个可能性并不大，因为[watchdog/x]本身也是实时进程，调度策略为SCHED_FIFO，优先级已经是最高的99：
123456789 | $ ps -ef | grep watchdogroot 6 2 0 Feb24 ? 00:00:18 [watchdog/0]root 10 2 0 Feb24 ? 00:00:16 [watchdog/1]root 14 2 0 Feb24 ? 00:00:13 [watchdog/2]root 18 2 0 Feb24 ? 00:00:12 [watchdog/3] $ chrt -p 6pid 6's current scheduling policy: SCHED_FIFOpid 6's current scheduling priority: 99 |
|---|
如果占着CPU不放的实时进程也是SCHED_FIFO并且优先级为99，就有可能导致soft lockup。为什么呢？我们看一下实时进程的调度策略就明白了：
- 在多个实时进程之间，优先级更高的会抢先运行 （注：实时进程的优先级数字越大则优先级越高，99最高，0最低；而普通进程正好相反，优先级数字越大则优先级越低，139最低，100最高）；
- 优先级相同的实时进程之间，不会互相抢占，只能等对方主动释放CPU；
- SCHED_FIFO调度策略的特点是，进程会一直保持运行直到发生以下情况之一：
- 进程主动调用sched_yield(2)放弃运行，自动排到运行队列的队尾，等到相同优先级的其它进程运行之后才有机会再运行；
- 进程进入睡眠状态（比如由于等待I/O的原因），唤醒后自动排到运行队列的队尾，等到相同优先级的其它进程运行之后才有机会再运行；
- 被优先级更高的实时进程抢占，这种情况下会自动排到运行队列的队首，下次运行的机会排在相同优先级的其它进程的前面。
- SCHED_RR进程与SCHED_FIFO唯一不同的是，实时进程的运行时间是分为一段一段的，在相同优先级的进程之间轮流运行，每个进程运行完一个时间段之后，必须让给下一个进程（强调：仅对相同优先级而言，不同优先级的进程之间仍然会互相抢占）。
所以，如果占着CPU不放的实时进程的调度策略是SCHED_FIFO，并且优先级为与[watchdog/x]相同的99，SCHED_FIFO的调度策略决定了只要它不放手，[watchdog/x]就无法运行，结果是会导致soft lockup。
接下来第二个问题是：
实时进程会不会导致其它进程得不到运行机会？
如果实时进程占着CPU不放，会不会导致其它进程得不到运行机会，包括管理员的shell也无法运行、连基本的管理任务也进行不了，最终造成整个系统失去控制？
通常不会。因为Linux kernel有一个RealTime Throttling机制，就是为了防止CPU消耗型的实时进程霸占所有的CPU资源而造成整个系统失去控制。它的原理很简单，就是保证无论如何普通进程都能得到一定比例（默认5%）的CPU时间，可以通过两个内核参数来控制：
- /proc/sys/kernel/sched_rt_period_us 缺省值是1,000,000 μs (1秒)，表示实时进程的运行粒度为1秒。（注：修改这个参数请谨慎，太大或太小都可能带来问题）。
- /proc/sys/kernel/sched_rt_runtime_us 缺省值是 950,000 μs (0.95秒)，表示在1秒的运行周期里所有的实时进程一起最多可以占用0.95秒的CPU时间。 如果sched_rt_runtime_us=-1，表示取消限制，意味着实时进程可以占用100%的CPU时间（慎用，有可能使系统失去控制）。
所以，Linux kernel的RealTime Throttling机制默认情况下保证了普通进程无论如何都可以得到5%的CPU时间，尽管系统可能会慢如蜗牛，但管理员仍然可以利用这5%的时间设法恢复系统，比如停掉失控的实时进程，或者给自己的shell进程赋予更高的实时优先级以便执行管理任务，等等。
Real-time Throttling支持cgroup，详见https://www.kernel.org/doc/Documentation/scheduler/sched-rt-group.txt
参考资料： https://lwn.net/Articles/296419/