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

来源：互联网发布：中国和德国的关系知乎编辑：程序博客网时间：2024/04/29 02:22

今天无意中看了眼 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. }