Linux-2.6 内核软中断(softirq)执行分析

今天无意中看了眼 2.6
内核的软中断实现，发现和以前我看到的大不相同（以前也是走马观花，不大仔细），能说改动非常大。连 softirq
的调用点都不相同了，以前是三个调用点，今天搜索了一下原始码，发目前多出了ksoftirqd
这个东西后，softirq
在系统中的调用点仅是在 ISR
返回时和使用了 local_bh_enable()
函数后被调用了。网卡部分的显示调用，我觉得应该不算是系统中的调用点。ksoftirqd
返回去调用 do_softirq()
函数应该也只能算是其中的一个分支，因为其本身从源头上来讲也还是在 ISR
返回时 irq_exit()
调用的。这样一来就和前些日子写的那份笔记（视窗系统/Linux/Solaris
软中断机制）里介绍的 Linux
内核部分的软中断有出处了，看来以后讨论 Linux kernel
代码一定要以内核版本为前题来说，要不非乱了不可。看来得买本 Linux
方面的书了，每次上来直接看相关代码也不是回事，时间也不允许。

linux kernel source 2.6.19.1

/kernel/softirq.c

1.
//
2.
// do_IRQ 函数执行完硬件 ISR 后退出时调用此函数。
3.
//
4.
void irq_exit(void)
5.
{
6.
account_system_vtime(current);
7.
trace_hardirq_exit();
8.
sub_preempt_count(IRQ_EXIT_OFFSET);
9.
//

10.
// 判断当前是否有硬件中断嵌套，并且是否有软中断在
11.
// pending 状态，注意：这里只有两个条件同时满足
12.
// 时，才有可能调用 do_softirq() 进入软中断。也就是
13.
// 说确认当前所有硬件中断处理完成，且有硬件中断安装了
14.
// 软中断处理时理时才会进入。
15.
//

16.
if (!in_interrupt() && local_softirq_pending())
17.
//

18.
// 其实这里就是调用 do_softirq() 执行
19.
//

20.
invoke_softirq();
21.
preempt_enable_no_resched();
22.
}
23.
#ifndef __ARCH_HAS_DO_SOFTIRQ
24.
asmlinkage void do_softirq(void)
25.
{
26.
__u32 pending;
27.
unsigned long flags;
28.
//

29.
// 这个函数判断，如果当前有硬件中断嵌套，或
30.
// 有软中断正在执行时候，则马上返回。在这个
31.
// 入口判断主要是为了和 ksoftirqd 互斥。
32.
//

33.
if (in_interrupt())
34.
return;
35.
//

36.
// 关中断执行以下代码
37.
//

38.
local_irq_save(flags);
39.
//

40.
// 判断是否有 pending 的软中断需要处理。
41.
//

42.
pending = local_softirq_pending();
43.
//

44.
// 如果有则调用 __do_softirq() 进行实际处理
45.
//

46.
if (pending)
47.
__do_softirq();
48.
//

49.
// 开中断继续执行
50.
//

51.
local_irq_restore(flags);
52.
}
53.
//
54.
// 最大软中断调用次数为 10 次。
55.
//
56.
#define MAX_SOFTIRQ_RESTART 10
57.
asmlinkage void __do_softirq(void)
58.
{
59.
//

60.
// 软件中断处理结构，此结构中包括了 ISR 中
61.
// 注册的回调函数。
62.
//

63.
struct softirq_action *h;
64.
__u32 pending;
65.
int max_restart = MAX_SOFTIRQ_RESTART;
66.
int cpu;
67.
//

68.
// 得到当前所有 pending 的软中断。
69.
//

70.
pending = local_softirq_pending();
71.
account_system_vtime(current);
72.
//

73.
// 执行到这里要屏蔽其他软中断，这里也就证实了
74.
// 每个 CPU 上同时运行的软中断只能有一个。
75.
//

76.
__local_bh_disable((unsigned long)__builtin_return_address(0));
77.
trace_softirq_enter();
78.
//

79.
// 针对 SMP 得到当前正在处理的 CPU

80.
//

81.
cpu = smp_processor_id();
82.
//
83.
// 循环标志
84.
//
85.
restart:
86.
//

87.
// 每次循环在允许硬件 ISR 强占前，首先重置软中断
88.
// 的标志位。
89.
//

90.
/* Reset the pending bitmask before enabling irqs */
91.
set_softirq_pending(0);
92.
//

93.
// 到这里才开中断运行，注意：以前运行状态一直是关中断
94.
// 运行，这时当前处理软中断才可能被硬件中断抢占。也就
95.
// 是说在进入软中断时不是一开始就会被硬件中断抢占。只有
96.
// 在这里以后的代码才可能被硬件中断抢占。
97.
//

98.
local_irq_enable();
99.
//

100.
// 这里要注意，以下代码运行时能被硬件中断抢占，但
101.
// 这个硬件 ISR 执行完成后，他的所注册的软中断无法马上运行，
102.
// 别忘了，目前虽是开硬件中断执行，但前面的 __local_bh_disable()

103.
// 函数屏蔽了软中断。所以这种环境下只能被硬件中断抢占，但这
104.
// 个硬中断注册的软中断回调函数无法运行。要问为什么，那是因为
105.
// __local_bh_disable() 函数设置了一个标志当作互斥量，而这个
106.
// 标志正是上面的 irq_exit() 和 do_softirq() 函数中的
107.
// in_interrupt() 函数判断的条件之一，也就是说 in_interrupt()

108.
// 函数不仅检测硬中断而且还判断了软中断。所以在这个环境下触发
109.
// 硬中断时注册的软中断，根本无法重新进入到这个函数中来，只能
110.
// 是做一个标志，等待下面的重复循环（最大 MAX_SOFTIRQ_RESTART）
111.
// 才可能处理到这个时候触发的硬件中断所注册的软中断。
112.
//

113.
//

114.
// 得到软中断向量表。
115.
//

116.
h = softirq_vec;
117.
//

118.
// 循环处理所有 softirq 软中断注册函数。
119.
//

120.
do {
121.
//

122.
// 如果对应的软中断设置 pending 标志则表明
123.
// 需要进一步处理他所注册的函数。
124.
//

125.
if (pending & 1) {
126.
//

127.
// 在这里执行了这个软中断所注册的回调函数。
128.
//

129.
h->action(h);
130.
rcu_bh_qsctr_inc(cpu);
131.
}
132.
//

133.
// 继续找，直到把软中断向量表中所有 pending 的软
134.
// 中断处理完成。
135.
//

136.
h++;
137.
//

138.
// 从代码里能看出按位操作，表明一次循环只
139.
// 处理 32 个软中断的回调函数。
140.
//

141.
pending >>= 1;
142.
} while (pending);
143.
//

144.
// 关中断执行以下代码。注意：这里又关中断了，下面的
145.
// 代码执行过程中硬件中断无法抢占。
146.
//

147.
local_irq_disable();
148.
//

149.
// 前面提到过，在刚才开硬件中断执行环境时只能被硬件中断
150.
// 抢占，在这个时候是无法处理软中断的，因为刚才开中
151.
// 断执行过程中可能多次被硬件中断抢占，每抢占一次就有可
152.
// 能注册一个软中断，所以要再重新取一次所有的软中断。
153.
// 以便下面的代码进行处理后跳回到 restart 处重复执行。
154.
//

155.
pending = local_softirq_pending();
156.
//

157.
// 如果在上面的开中断执行环境中触发了硬件中断，且每个都
158.
// 注册了一个软中断的话，这个软中断会设置 pending 位，
159.
// 但在当前一直屏蔽软中断的环境下无法得到执行，前面提
160.
// 到过，因为 irq_exit() 和 do_softirq() 根本无法进入到
161.
// 这个处理过程中来。这个在上面周详的记录过了。那么在
162.
// 这里又有了一个执行的机会。注意：虽然当前环境一直是
163.
// 处于屏蔽软中断执行的环境中，但在这里又给出了一个执行
164.
// 刚才在开中断环境过程中触发硬件中断时所注册的软中断的
165.
// 机会，其实只要理解了软中断机制就会知道，无非是在一些特
166.
// 定环境下调用 ISR 注册到软中断向量表里的函数而已。
167.
//

168.
//

169.
// 如果刚才触发的硬件中断注册了软中断，并且重复执行次数
170.
// 没有到 10 次的话，那么则跳转到 restart 标志处重复以上
171.
// 所介绍的所有步骤：设置软中断标志位，重新开中断执行...

172.
// 注意：这里是要两个条件都满足的情况下才可能重复以上步骤。

173.
//

174.
if (pending && --max_restart)
175.
goto restart;
176.
//

177.
// 如果以上步骤重复了 10 次后更有 pending 的软中断的话，
178.
// 那么系统在一定时间内可能达到了一个峰值，为了平衡这点。
179.
// 系统专门建立了一个 ksoftirqd 线程来处理，这样避免在一
180.
// 定时间内负荷太大。这个 ksoftirqd 线程本身是个大循环，
181.
// 在某些条件下为了不负载过重，他是能被其他进程抢占的，
182.
// 但注意，他是显示的调用了 preempt_xxx() 和 schedule()

183.
// 才会被抢占和转换的。这么做的原因是因为在他一旦调用

184.
// local_softirq_pending() 函数检测到有 pending 的软中断
185.
// 需要处理的时候，则会显示的调用 do_softirq() 来处理软中
186.
// 断。也就是说，下面代码唤醒的 ksoftirqd 线程有可能会回
187.
// 到这个函数当中来，尤其是在系统需要响应非常多软中断的情况
188.
// 下，他的调用入口是 do_softirq()，这也就是为什么在 do_softirq()

189.
// 的入口处也会用 in_interrupt() 函数来判断是否有软中断
190.
// 正在处理的原因了，目的还是为了防止重入。ksoftirqd 实现
191.
// 看下面对 ksoftirqd() 函数的分析。
192.
//

193.
if (pending)
194.
//

195.
// 此函数实际是调用 wake_up_process() 来唤醒 ksoftirqd

196.
//

197.
wakeup_softirqd();
198.
trace_softirq_exit();
199.
account_system_vtime(current);
200.
//

201.
// 到最后才开软中断执行环境，允许软中断执行。注意：这里
202.
// 使用的不是 local_bh_enable()，不会再次触发 do_softirq()

203.
// 的调用。
204.
//

205.
_local_bh_enable();
206.
}
207.
static int ksoftirqd(void * __bind_cpu)
208.
{
209.
//

210.
// 显示调用此函数设置当前进程的静态优先级。当然，
211.
// 这个优先级会随调度器策略而变化。
212.
//

213.
set_user_nice(current, 19);
214.
//

215.
// 设置当前进程不允许被挂启
216.
//

217.
current->flags |= PF_NOFREEZE;
218.
//

219.
// 设置当前进程状态为可中断的状态，这种睡眠状
220.
// 态可响应信号处理等。
221.
//

222.
set_current_state(TASK_INTERRUPTIBLE);
223.
//

224.
// 下面是个大循环，循环判断当前进程是否会停止，
225.
// 不会则继续判断当前是否有 pending 的软中断需
226.
// 要处理。
227.
//

228.
while (!kthread_should_stop()) {
229.
//

230.
// 如果能进行处理，那么在此处理期间内禁止
231.
// 当前进程被抢占。
232.
//

233.
preempt_disable();
234.
//

235.
// 首先判断系统当前没有需要处理的 pending 状态的
236.
// 软中断
237.
//

238.
if (!local_softirq_pending()) {
239.
//

240.
// 没有的话在主动放弃 CPU 前先要允许抢占，因为
241.
// 一直是在不允许抢占状态下执行的代码。
242.
//

243.
preempt_enable_no_resched();
244.
//

245.
// 显示调用此函数主动放弃 CPU 将当前进程放入睡眠队列，
246.
// 并转换新的进程执行（调度器相关不记录在此）
247.
//

248.
schedule();
249.
//

250.
// 注意：如果当前显示调用 schedule() 函数主动转换的进
251.
// 程再次被调度执行的话，那么将从调用这个函数的下一条
252.
// 语句开始执行。也就是说，在这里当前进程再次被执行的
253.
// 话，将会执行下面的 preempt_disable() 函数。
254.
//

255.
//

256.
// 当进程再度被调度时，在以下处理期间内禁止当前进程
257.
// 被抢占。
258.
//

259.
preempt_disable();
260.
}
261.
//

262.
// 设置当前进程为运行状态。注意：已设置了当前进程不可抢占
263.
// 在进入循环后，以上两个分支不论走哪个都会执行到这里。一是
264.
// 进入循环时就有 pending 的软中断需要执行时。二是进入循环时
265.
// 没有 pending 的软中断，当前进程再次被调度获得 CPU 时继续
266.
// 执行时。
267.
//

268.
__set_current_state(TASK_RUNNING);
269.
//

270.
// 循环判断是否有 pending 的软中断，如果有则调用 do_softirq()

271.
// 来做具体处理。注意：这里又是个 do_softirq() 的入口点，
272.
// 那么在 __do_softirq() 当中循环处理 10 次软中断的回调函数
273.
// 后，如果更有 pending 的话，会又调用到这里。那么在这里则
274.
// 又会有可能去调用 __do_softirq() 来处理软中断回调函数。在前
275.
// 面介绍 __do_softirq() 时已提到过，处理 10 次还处理不完的
276.
// 话说明系统正处于繁忙状态。根据以上分析，我们能试想如果在
277.
// 系统非常繁忙时，这个进程将会和 do_softirq() 相互交替执行，
278.
// 这时此进程占用 CPU 应该会非常高，虽然下面的 cond_resched()

279.
// 函数做了一些处理，他在处理完一轮软中断后当前处理进程可能会
280.
// 因被调度而减少 CPU 负荷，不过在非常繁忙时这个进程仍然有可
281.
// 能大量占用 CPU。
282.
//

283.
while (local_softirq_pending()) {
284.
/* Preempt disable stops cpu going offline.
285.
If already offline, we’ll be on wrong CPU:
286.
don’t process */
287.
if (cpu_is_offline((long)__bind_cpu))
288.
//

289.
// 如果当前被关联的 CPU 无法继续处理则跳转
290.
// 到 wait_to_die 标记出，等待结束并退出。
291.
//

292.
goto wait_to_die;
293.
//

294.
// 执行 do_softirq() 来处理具体的软中断回调函数。注
295.
// 意：如果此时有一个正在处理的软中断的话，则会马上
296.
// 返回，还记得前面介绍的 in_interrupt() 函数么。
297.
//

298.
do_softirq();
299.
//

300.
// 允许当前进程被抢占。
301.
//

302.
preempt_enable_no_resched();
303.

304.
//

305.
// 这个函数有可能间接的调用 schedule() 来转换当前
306.
// 进程，而且上面已允许当前进程可被抢占。也就是
307.
// 说在处理完一轮软中断回调函数时，有可能会转换到
308.
// 其他进程。我认为这样做的目的一是为了在某些负载
309.
// 超标的情况下不至于让这个进程长时间大量的占用 CPU，
310.
// 二是让在有非常多软中断需要处理时不至于让其他进程
311.
// 得不到响应。
312.
//

313.
cond_resched();
314.
//

315.
// 禁止当前进程被抢占。
316.
//

317.
preempt_disable();
318.
//

319.
// 处理完所有软中断了吗？没有的话继续循环以上步骤
320.
//

321.
}
322.
//

323.
// 待一切都处理完成后，允许当前进程被抢占，并设置
324.
// 当前进程状态为可中断状态，继续循环以上所有过程。
325.
//

326.
preempt_enable();
327.
set_current_state(TASK_INTERRUPTIBLE);
328.
}
329.

330.
//

331.
// 如果将会停止则设置当前进程为运行状态后直接返回。
332.
// 调度器会根据优先级来使当前进程运行。
333.
//

334.
__set_current_state(TASK_RUNNING);
335.
return 0;
336.
//
337.
// 一直等待到当前进程被停止
338.
//
339.
wait_to_die:
340.
//

341.
// 允许当前进程被抢占。
342.
//

343.
preempt_enable();
344.
/* Wait for kthread_stop */
345.
//

346.
// 设置当前进程状态为可中断的状态，这种睡眠状
347.
// 态可响应信号处理等。
348.
//

349.
set_current_state(TASK_INTERRUPTIBLE);
350.
//

351.
// 判断当前进程是否会被停止，如果不是的话
352.
// 则设置进程状态为可中断状态并放弃当前 CPU

353.
// 主动转换。也就是说这里将一直等待当前进程
354.
// 将被停止时候才结束。
355.
//

356.
while (!kthread_should_stop()) {
357.
schedule();
358.
set_current_state(TASK_INTERRUPTIBLE);
359.
}
360.
//

361.
// 如果将会停止则设置当前进程为运行状态后直接返回。
362.
// 调度器会根据优先级来使当前进程运行。
363.
//

364.
__set_current_state(TASK_RUNNING);
365.
return 0;
366.
}