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

转载 2011年01月08日 20:12:00

本文对 Linux 内核软中断的执行流程进行了分析,并尽可能的结合当前运行环境详细地写出我的理解,但这并不表明我的理解一定正确。这本是论坛里的一篇帖子,发出来是为了抛砖引玉,如果您在阅读本文时发现了我的错误,还望得到您的指正。

 

今天无意中看了眼 2.6 内核的软中断实现,发现和以前我看到的大不相同(以前也是走马观花,不大仔细),可以说改动很大。连 softirq 的调用点都不一样了,以前是三个调用点,今天搜索了一下源代码,发现在多出了ksoftirqd 后,softirq 在系统中的调用点仅是在 ISR 返回时和使用了local_bh_enable() 函数后被调用了。网卡部分的显示调用,我觉得应该不算是系统中的调用点。ksoftirqd 返回去调用 do_softirq() 函数应该也只能算是其中的一个分支,因为其本身从源头上来讲也还是在 ISR 返回时 irq_exit() 调用的。这样一来就和前些日子写的那份笔记(Windows/Linux

/Solaris 软中断机制)里介绍的 Linux 内核部分的软中断有出处了,看来以后讨论 Linux kernel 代码一定要以内核版本为前题,要不非乱了不可。得买本 Linux 方面的书了,每次上来直接看相关代码也不是回事,时间也不允许。

 

001 //
002 // do_IRQ 函数执行完硬件 ISR 后退出时调用此函数。
003 //
004   
005 void irq_exit(void)
006 {
007         account_system_vtime(current);
008         trace_hardirq_exit();
009         sub_preempt_count(IRQ_EXIT_OFFSET);
010   
011         //
012         // 判断当前是否有硬件中断嵌套,并且是否有软中断在
013         // pending 状态,注意:这里只有两个条件同时满足
014         // 时,才有可能调用 do_softirq() 进入软中断。也就是
015         // 说确认当前所有硬件中断处理完成,且有硬件中断安装了
016         // 软中断处理时理时才会进入。
017         // 
018         if (!in_interrupt() && local_softirq_pending())
019   
020                 //
021                 // 其实这里就是调用 do_softirq() 执行
022                 //
023                 invoke_softirq();
024         preempt_enable_no_resched();
025 }
026   
027   
028 #ifndef __ARCH_HAS_DO_SOFTIRQ
029   
030 asmlinkage void do_softirq(void)
031 {
032         __u32 pending;
033         unsigned long flags;
034   
035         //
036         // 这个函数判断,如果当前有硬件中断嵌套,或者
037         // 有软中断正在执行时候,则马上返回。在这个
038         // 入口判断主要是为了与 ksoftirqd 互斥。
039         //
040         if (in_interrupt())
041                 return;
042   
043         //
044         // 关中断执行以下代码
045         //
046         local_irq_save(flags);
047   
048         //
049         // 判断是否有 pending 的软中断需要处理。
050         //
051         pending = local_softirq_pending();
052   
053         //
054         // 如果有则调用 __do_softirq() 进行实际处理
055         //
056         if (pending)
057                 __do_softirq();
058   
059         //
060         // 开中断继续执行
061         //
062         local_irq_restore(flags);
063 }
064   
065   
066 //
067 // 最大软中断调用次数为 10 次。
068 //
069   
070 #define MAX_SOFTIRQ_RESTART 10
071   
072 asmlinkage void __do_softirq(void)
073 {
074         //
075         // 软件中断处理结构,此结构中包括了 ISR 中
076         // 注册的回调函数。
077         //
078         struct softirq_action *h;
079         __u32 pending;
080         int max_restart = MAX_SOFTIRQ_RESTART;
081         int cpu;
082   
083         //
084         // 得到当前所有 pending 的软中断。
085         // 
086         pending = local_softirq_pending();
087         account_system_vtime(current);
088   
089         //
090         // 执行到这里要屏蔽其他软中断,这里也就证明了
091         // 每个 CPU 上同时运行的软中断只能有一个。
092         //
093         __local_bh_disable((unsigned long)__builtin_return_address(0));
094         trace_softirq_enter();
095   
096         //
097         // 针对 SMP 得到当前正在处理的 CPU
098         //
099         cpu = smp_processor_id();
100 //
101 // 循环标志
102 //
103 restart:
104         //
105         // 每次循环在允许硬件 ISR 强占前,首先重置软中断
106         // 的标志位。
107         //
108         /* Reset the pending bitmask before enabling irqs */
109         set_softirq_pending(0);
110   
111         //
112         // 到这里才开中断运行,注意:以前运行状态一直是关中断
113         // 运行,这时当前处理软中断才可能被硬件中断抢占。也就
114         // 是说在进入软中断时不是一开始就会被硬件中断抢占。只有
115         // 在这里以后的代码才可能被硬件中断抢占。
116         //
117         local_irq_enable();
118   
119         //
120         // 这里要注意,以下代码运行时可以被硬件中断抢占,但
121         // 这个硬件 ISR 执行完成后,它的所注册的软中断无法马上运行,
122         // 别忘了,现在虽是开硬件中断执行,但前面的 __local_bh_disable()
123         // 函数屏蔽了软中断。所以这种环境下只能被硬件中断抢占,但这
124         // 个硬中断注册的软中断回调函数无法运行。要问为什么,那是因为
125         // __local_bh_disable() 函数设置了一个标志当作互斥量,而这个
126         // 标志正是上面的 irq_exit() 和 do_softirq() 函数中的
127         // in_interrupt() 函数判断的条件之一,也就是说 in_interrupt() 
128         // 函数不仅检测硬中断而且还判断了软中断。所以在这个环境下触发
129         // 硬中断时注册的软中断,根本无法重新进入到这个函数中来,只能
130         // 是做一个标志,等待下面的重复循环(最大 MAX_SOFTIRQ_RESTART)
131         // 才可能处理到这个时候触发的硬件中断所注册的软中断。
132         //
133   
134   
135         //
136         // 得到软中断向量表。
137         //
138         h = softirq_vec;
139   
140         //
141         // 循环处理所有 softirq 软中断注册函数。
142         // 
143         do {
144                 //
145                 // 如果对应的软中断设置 pending 标志则表明
146                 // 需要进一步处理它所注册的函数。
147                 //
148                 if (pending & 1) {
149                         //
150                         // 在这里执行了这个软中断所注册的回调函数。
151                         //
152                         h->action(h);
153                         rcu_bh_qsctr_inc(cpu);
154                 }
155         //
156         // 继续找,直到把软中断向量表中所有 pending 的软
157         // 中断处理完成。
158         //
159                 h++;
160   
161                 //
162                 // 从代码里可以看出按位操作,表明一次循环只
163                 // 处理 32 个软中断的回调函数。
164                 //
165                 pending >>= 1; 
166         } while (pending);
167   
168         //
169         // 关中断执行以下代码。注意:这里又关中断了,下面的
170         // 代码执行过程中硬件中断无法抢占。
171         //
172         local_irq_disable();
173   
174         //
175         // 前面提到过,在刚才开硬件中断执行环境时只能被硬件中断
176         // 抢占,在这个时候是无法处理软中断的,因为刚才开中
177         // 断执行过程中可能多次被硬件中断抢占,每抢占一次就有可
178         // 能注册一个软中断,所以要再重新取一次所有的软中断。
179         // 以便下面的代码进行处理后跳回到 restart 处重复执行。
180         //
181         pending = local_softirq_pending();
182   
183         //
184         // 如果在上面的开中断执行环境中触发了硬件中断,且每个都
185         // 注册了一个软中断的话,这个软中断会设置 pending 位,
186         // 但在当前一直屏蔽软中断的环境下无法得到执行,前面提
187         // 到过,因为 irq_exit() 和 do_softirq() 根本无法进入到
188         // 这个处理过程中来。这个在上面详细的记录过了。那么在
189         // 这里又有了一个执行的机会。注意:虽然当前环境一直是
190         // 处于屏蔽软中断执行的环境中,但在这里又给出了一个执行
191         // 刚才在开中断环境过程中触发硬件中断时所注册的软中断的
192         // 机会,其实只要理解了软中断机制就会知道,无非是在一些特
193         // 定环境下调用 ISR 注册到软中断向量表里的函数而已。
194         //
195   
196         //
197         // 如果刚才触发的硬件中断注册了软中断,并且重复执行次数
198         // 没有到 10 次的话,那么则跳转到 restart 标志处重复以上
199         // 所介绍的所有步骤:设置软中断标志位,重新开中断执行...
200         // 注意:这里是要两个条件都满足的情况下才可能重复以上步骤。 
201         //
202         if (pending && --max_restart)
203                 goto restart;
204   
205         //
206         // 如果以上步骤重复了 10 次后还有 pending 的软中断的话,
207         // 那么系统在一定时间内可能达到了一个峰值,为了平衡这点。
208         // 系统专门建立了一个 ksoftirqd 线程来处理,这样避免在一
209         // 定时间内负荷太大。这个 ksoftirqd 线程本身是一个大循环,
210         // 在某些条件下为了不负载过重,它是可以被其他进程抢占的,
211         // 但注意,它是显示的调用了 preempt_xxx() 和 schedule()
212         // 才会被抢占和切换的。这么做的原因是因为在它一旦调用 
213         // local_softirq_pending() 函数检测到有 pending 的软中断
214         // 需要处理的时候,则会显示的调用 do_softirq() 来处理软中
215         // 断。也就是说,下面代码唤醒的 ksoftirqd 线程有可能会回
216         // 到这个函数当中来,尤其是在系统需要响应很多软中断的情况
217         // 下,它的调用入口是 do_softirq(),这也就是为什么在 do_softirq()
218         // 的入口处也会用 in_interrupt()  函数来判断是否有软中断
219         // 正在处理的原因了,目的还是为了防止重入。ksoftirqd 实现
220         // 看下面对 ksoftirqd() 函数的分析。
221         //
222         if (pending)
223   
224                //
225                // 此函数实际是调用 wake_up_process() 来唤醒 ksoftirqd
226                // 
227                 wakeup_softirqd();
228   
229         trace_softirq_exit();
230   
231         account_system_vtime(current);
232   
233         //
234         // 到最后才开软中断执行环境,允许软中断执行。注意:这里
235         // 使用的不是 local_bh_enable(),不会再次触发 do_softirq()
236         // 的调用。
237         // 
238         _local_bh_enable();
239 }
240   
241   
242   
243 static int ksoftirqd(void * __bind_cpu)
244 {
245   
246         //
247         // 显示调用此函数设置当前进程的静态优先级。当然,
248         // 这个优先级会随调度器策略而变化。
249         //
250         set_user_nice(current, 19);
251   
252         //
253         // 设置当前进程不允许被挂启
254         //
255         current->flags |= PF_NOFREEZE;
256   
257         //
258         // 设置当前进程状态为可中断的状态,这种睡眠状
259         // 态可响应信号处理等。
260         // 
261         set_current_state(TASK_INTERRUPTIBLE);
262   
263         //
264         // 下面是一个大循环,循环判断当前进程是否会停止,
265         // 不会则继续判断当前是否有 pending 的软中断需
266         // 要处理。
267         //
268         while (!kthread_should_stop()) {
269   
270                 //
271                 // 如果可以进行处理,那么在此处理期间内禁止
272                 // 当前进程被抢占。
273                 //
274                 preempt_disable();
275   
276                 //
277                 // 首先判断系统当前没有需要处理的 pending 状态的
278                 // 软中断
279                 //
280                 if (!local_softirq_pending()) {
281   
282                         //
283                         // 没有的话在主动放弃 CPU 前先要允许抢占,因为
284                         // 一直是在不允许抢占状态下执行的代码。
285                         //
286                         preempt_enable_no_resched();
287   
288                         //
289                         // 显示调用此函数主动放弃 CPU 将当前进程放入睡眠队列,
290                         // 并切换新的进程执行(调度器相关不记录在此)
291                         //
292                         schedule();
293   
294                         //
295                         // 注意:如果当前显示调用 schedule() 函数主动切换的进
296                         // 程再次被调度执行的话,那么将从调用这个函数的下一条
297                         // 语句开始执行。也就是说,在这里当前进程再次被执行的
298                         // 话,将会执行下面的 preempt_disable() 函数。
299                         //
300   
301                         //
302                         // 当进程再度被调度时,在以下处理期间内禁止当前进程
303                         // 被抢占。
304                         //
305                         preempt_disable();
306                 }
307   
308                 //
309                 // 设置当前进程为运行状态。注意:已经设置了当前进程不可抢占
310                 // 在进入循环后,以上两个分支不论走哪个都会执行到这里。一是
311                 // 进入循环时就有 pending 的软中断需要执行时。二是进入循环时
312                 // 没有 pending 的软中断,当前进程再次被调度获得 CPU 时继续
313                 // 执行时。
314                 //
315                 __set_current_state(TASK_RUNNING);
316   
317                 //
318                 // 循环判断是否有 pending 的软中断,如果有则调用 do_softirq()
319                 // 来做具体处理。注意:这里又是一个 do_softirq() 的入口点,
320                 // 那么在 __do_softirq() 当中循环处理 10 次软中断的回调函数
321                 // 后,如果还有 pending 的话,会又调用到这里。那么在这里则
322                 // 又会有可能去调用 __do_softirq() 来处理软中断回调函数。在前
323                 // 面介绍 __do_softirq() 时已经提到过,处理 10 次还处理不完的
324                 // 话说明系统正处于繁忙状态。根据以上分析,我们可以试想如果在
325                 // 系统非常繁忙时,这个进程将会与 do_softirq() 相互交替执行,
326                 // 这时此进程占用 CPU 应该会很高,虽然下面的 cond_resched() 
327                 // 函数做了一些处理,它在处理完一轮软中断后当前处理进程可能会
328                 // 因被调度而减少 CPU 负荷,但是在非常繁忙时这个进程仍然有可
329                 // 能大量占用 CPU。
330                 //
331                 while (local_softirq_pending()) {
332                         /* Preempt disable stops cpu going offline.
333                            If already offline, we'll be on wrong CPU:
334                            don't process */
335                         if (cpu_is_offline((long)__bind_cpu))
336   
337                                 //
338                                 // 如果当前被关联的 CPU 无法继续处理则跳转
339                                 // 到 wait_to_die 标记出,等待结束并退出。
340                                 // 
341                                 goto wait_to_die;
342   
343                         //
344                         // 执行 do_softirq() 来处理具体的软中断回调函数。注
345                         // 意:如果此时有一个正在处理的软中断的话,则会马上
346                         // 返回,还记得前面介绍的 in_interrupt() 函数么。
347                         //
348                         do_softirq();
349   
350                         //
351                         // 允许当前进程被抢占。
352                         //
353                         preempt_enable_no_resched();
354                           
355                         //
356                         // 这个函数有可能间接的调用 schedule() 来切换当前
357                         // 进程,而且上面已经允许当前进程可被抢占。也就是
358                         // 说在处理完一轮软中断回调函数时,有可能会切换到
359                         // 其他进程。我认为这样做的目的一是为了在某些负载
360                         // 超标的情况下不至于让这个进程长时间大量的占用 CPU,
361                         // 二是让在有很多软中断需要处理时不至于让其他进程
362                         // 得不到响应。
363                         //
364                         cond_resched();
365   
366                         //
367                         // 禁止当前进程被抢占。
368                         //
369                         preempt_disable();
370   
371                         //
372                         // 处理完所有软中断了吗?没有的话继续循环以上步骤
373                         //
374                 }
375   
376                 //
377                 // 待一切都处理完成后,允许当前进程被抢占,并设置
378                 // 当前进程状态为可中断状态,继续循环以上所有过程。
379                 //
380                 preempt_enable();
381                 set_current_state(TASK_INTERRUPTIBLE);
382         }
383      
384         //
385         // 如果将会停止则设置当前进程为运行状态后直接返回。
386         // 调度器会根据优先级来使当前进程运行。
387         //
388         __set_current_state(TASK_RUNNING);
389         return 0;
390   
391 //
392 // 一直等待到当前进程被停止
393 //
394 wait_to_die:
395   
396         //
397         // 允许当前进程被抢占。
398         //
399         preempt_enable();
400         /* Wait for kthread_stop */
401   
402         //
403         // 设置当前进程状态为可中断的状态,这种睡眠状
404         // 态可响应信号处理等。
405         // 
406         set_current_state(TASK_INTERRUPTIBLE);
407   
408         //
409         // 判断当前进程是否会被停止,如果不是的话
410         // 则设置进程状态为可中断状态并放弃当前 CPU
411         // 主动切换。也就是说这里将一直等待当前进程
412         // 将被停止时候才结束。
413         //
414         while (!kthread_should_stop()) {
415                 schedule();
416                 set_current_state(TASK_INTERRUPTIBLE);
417         }
418   
419         //
420         // 如果将会停止则设置当前进程为运行状态后直接返回。
421         // 调度器会根据优先级来使当前进程运行。
422         //
423         __set_current_state(TASK_RUNNING);
424         return 0;
425 }

相关文章推荐

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

http://blog.csdn.net/leopard_ray/archive/2007/11/08/1874148.aspx     今天无意中看了眼 2.6 内核的软中断实现,...

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

今天无意中看了眼 2.6 内核的软中断实现,发现和以前我看到的大不相同(以前也是走马观花,不大仔细),能说改动非常大。连 softirq 的调用点都不相同了,以前是三个调用点,今天搜索了一下原始...

Linux softirq(软中断)

1. 软中断简介 在linux内核中,硬件中断

Linux内核修炼之软中断分析

====本文系本站原创,欢迎转载! 转载请注明出处:http://blog.csdn.net/yyplc====  基于内核:linux-2.6.30.4   arm平台分析. 中断分成硬中断和软...
  • yyplc
  • yyplc
  • 2012年05月19日 22:27
  • 3289

浅谈linux2.4 内核中断下半部分(softirq机制)

linux2.4 内核中断下半部分(bottom half)理解(请结合linux2.4内核代码看): 首先先说一下为什么要采用中断下半部分: 中断服务函数大多需要在关中断的情况下去执行,但是有的...

linux 内核笔记--中断子系统之softirq

linux把处理硬件中断的过程分为两部分。上半部简单快速,执行时禁止部分或全部中断。下半部稍后执行,并且执行期间可以响应所有的中断。这样的设计会使系统处于中断屏蔽的状态尽可能的短,从而提高系统的响应能...

Linux 2.4.x内核软中断机制.pdf

  • 2008年04月15日 21:38
  • 210KB
  • 下载

softirq(软中断)下半部中tasklet与workqueue的区别,整合

一、中断处理的tasklet(小任务)机制 中断服务程序一般都是在中断请求关闭的条件下执行的,以避免嵌套而使中断控制复杂化。但是,中断是一个随机事件,它随时会到来,如果关中断的时间太长,CPU就不能...

软中断SOFTIRQ

软中断的引入 软中断的出现和linux系统对中断的划分是分不开的。linux系统将整个中断处理过程分为了两部分,分别为上半部(Top Half)和下半部(Bottom Half),之所以要这样分是因为...

软中断(softirq)机制

Linux的中断宏观分为两种:软中断和硬中断。声明一下,这里的软和硬的意思是指和软件相关以及和硬件相关,而不是软件实现的中断或硬件实现的中断。 软中断就是"信号机制"。软中不是软件中断。Linux通...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Linux的内核软中断(softirq)执行分析
举报原因:
原因补充:

(最多只允许输入30个字)