是谁关闭了Linux抢占，而抢占又关闭了谁？

r囧r小猫 2023-07-18 04:42 9阅读 0赞

# 前言 #

本人的目的在于解惑，把读者从糊里糊涂的状态解救出来。本文对比分析：

*  preempt\_disable() 
 *  local\_irq\_disable()/local\_irq\_save(flags)
 *  spin\_lock()
 *  spin\_lock\_irq()/spin\_lock\_irqsave(lock, flags)

哪些关闭了抢占？另外，再说清楚，抢占又关闭了谁。

首先，把这几个API的关系图再勾勒一下。

我们理解，spin\_lock()会调用preempt\_disable() 导致本核的抢占调度被关闭(preempt\_disable函数实际增加preempt\_count来达到此效果)，其次我们理解spin\_lock\_irq()是local\_irq\_disable()+preempt\_disable()的合体。

![format_png][]

下面一幅图描述了几个函数之间的包含关系如下：

![format_png 1][]

![format_png 2][]

local\_irq\_disable()/local\_irq\_save()的disable和save版的唯一区别是，要不要保存CPU对中断的屏蔽状态。

spin\_lock\_irq()/spin\_lock\_irqsave(lock, flags)的唯一区别是，要不要保存CPU对中断的屏蔽状态。

# 是谁杀了抢占？ #

Kernel的代码明确显示，执行抢占调度的时候，会同时检测“non-zero preempt\_count or interrupts are disabled”：

![format_png 3][]

我们可以进一步展开preemptible()：

![format_png 4][]

对于ARM处理器而言，判断irqs\_disabled()，其实就是判断CPSR中的IRQMASK\_I\_BIT是否被设置。

所以，我们得出一个结论，前言这一节里面，列出的所有函数，都能关闭本核的抢占调度。因为，**无论是preempt\_count计数状态，还是中断被关闭，都会导致kernel认为无法抢占！**

通杀逻辑如下：

![format_png 5][]

![format_png 6][]

# 杀手的差异在哪里？ #

既然都关闭了抢占，那么区别在哪里呢？

我们看两段代码，假设下面的代码都发生在NICE为0的普通进程：

preempt\_disable()

**xxx(1)**

preempt\_enable()

和

local\_irq\_disable()

**xxx(2)**

local\_irq\_enable()

首先，xxx(1)和xxx(2)里面，都是不可以抢占的。一个搞定了preempt\_count，一个搞定了中断。

但是假设xxx(1)内唤醒了一个高优先级的RT任务，那么在preempt\_enable()的时刻，**直接就是一个抢占点，这个时候，发生schedule**，高优先级RT任务进来跑；假设xxx(2)内唤醒了一个高优先级的RT任务，那么在local\_irq\_enable()的时刻，不是一个抢占点，高优先级RT的任务必须等待下一个抢占点。下一个抢占点，可能是时钟tick处理返回、中断返回、软中断结束、yield()等等多种情况。

在preempt\_enable()中，会执行一次preempt\_schedule()：

![format_png 7][]

而local\_irq\_enable()只是单纯的开启CPU对中断的响应，对于ARM而言，它就是：

![format_png 8][]

再来看大boss，spin\_lock\_irq是同时调用了preempt\_disable和local\_irq\_disable：

![format_png 9][]

而对应的spin\_unlock\_irq()则同时调用了local\_irq\_enable()和preempt\_enable():

![format_png 10][]

大家想一想，为何preempt\_enable()比local\_irq\_enable()后发生呢？如果代码顺序是这样的：

preempt\_enable()

local\_irq\_enable()

第一句preempt\_enable()想执行抢占调度的话，即便调用了preempt\_schedule()，但是由于IRQ还是关门的，preempt\_schedule()函数会立即返回(详见《是谁杀了抢占？》一节)，所以无法抢占；后一句local\_irq\_enable()不会执行抢占调度。所以，如果这么干的话，

spin\_lock\_irq()

**xxx(3)**

spin\_unlock\_irq()

如果xxx(3)唤醒了高优先级的RT，在spin\_unlock\_irq()的时刻，将无法直接抢占！

还好，真正的顺序是：

local\_irq\_enable()

preempt\_enable()

所以，在spin\_unlock\_irq()的时刻，RT进程就换入执行了。

看小一点的boss，spin\_lock()：

spin\_lock()

**xxx(4)**

spin\_unlock()

如果xxx(4)唤醒了RT进程，在spin\_unlock()的时刻，会立即抢入。因为spin\_unlock()会调用preempt\_enable()。

而抢占又杀了谁？

理论上，关抢占，并没有彻底的关闭调度器，因为进程还是可以主动地sleep：

![format_png 11][]

上述代码，在spin\_lock的区间里面，调用了msleep()，这个时候，不属于抢占，Linux还是会pick下一个task来跑。

不过这样的代码，一般在后期蕴藏着巨大的风险，导致后期的莫名崩溃。所以呢，实际的工程里面，我们是严格地禁止的。

建议大家打开Kernel里面的config里面的DEBUG\_ATOMIC\_SLEEP,一旦出现这种情况，让kernel去汇报错误。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70][]

这种情况下，kernel检测到有人在atomic上下文里面执行可能睡眠的行为，会直接报执行的栈回溯。

[format_png]: /images/20230528/097a925fb45246448730dc55eef70db1.png
[format_png 1]: /images/20230528/e34cbfac373f4ba0bc88b3be8d8cb154.png
[format_png 2]: /images/20230528/350748c5708640339852f96ffca89667.png
[format_png 3]: /images/20230528/18621d4f21f2454cba04fd704984bb85.png
[format_png 4]: /images/20230528/9e67af50b4c2446a8cf89649491ad0c4.png
[format_png 5]: /images/20230528/2dcfb02a08fb4a63bac29992fe673e0f.png
[format_png 6]: /images/20230528/1edef126d0b24a6586606df18927ebe2.png
[format_png 7]: /images/20230528/8f66e899e1034d9b9b0c6551c3377ca2.png
[format_png 8]: /images/20230528/08cdf61183244d33ab7023416e58e76a.png
[format_png 9]: /images/20230528/3863d2f9fd0d48a0a8c652f0a282c17f.png
[format_png 10]: /images/20230528/77af6d1aad274a5e955aab8542a98df3.png
[format_png 11]: /images/20230528/f75659be15364aedaee2e1bff82d643d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70]: /images/20230528/59fb9789a64943d4aa45f7173fac275e.png