kk Blog —— 通用基础

date [-d @int|str] [+%s|"+%F %T"]

中断,进程

blog.chinaunix.net/uid-20806345-id-3203602.html

中断不是进程,不受内核调度器的管辖。在系统处理进程的过程中,对于某个cpu来说,如果有内部中断或外部中断到来,则切换到中断处理程序,切换首先要将进程由用户态要切到进程的内核态,然后再将cpu切换到中断态,待处理完中断返回进程的内核态,再返回进程的用户态,如果中断时进程刚好处于内核态中不用由用户态切到内核态了。
中断处理时是不分优先级的,处理中断的过程中如果有任意中断到来,都会抢占当前的中断处理过程。所以对于要及时响应的中断,需要通过关中断来屏蔽其他中断。通常所说的中断优先级是指中断控制器端的优先级,当有多个中断触发时,首先选择优先级高的中断发出请求给处理器。中断优先级只是对中断控制器而言的,所有的中断对cpu来说都是一样的,没有优先级高低之分。
关中断是关闭所有的外部可屏蔽中断,和优先级没有关系,如果在某中断处理程序中关中断,则不会被任何可屏蔽中断抢占,但是会被任意的不可屏蔽中断抢占。关中断是中断处理程序可选的。

bbs.chinaunix.net/thread-2306027-1-8.html

软中断做的是一些可延迟的费时间的事,当然不能在中断里执行了。
__do_softirq代码,可以看到在执行可延迟函数第一件事就是开中断。但在开始之前,禁用了下半部中断(__local_bh_disable)。这样就算被中断了,返回内核时也不会被抢占,还是执行这里的代码。也不会被调度。
那么这样的后果就是软中断上下文里的会一直执行下去,直到到达了限定次数,然后唤醒守护进程。
因为软中断切换了栈,不再使用进程上下文,那么如果在软中断上下文直接或简洁调用了shedule,那么只有死翘翘了!!因为schedule调度回来的时候是依赖进程内核栈的thread_info。

内核抢占点之一就是中断返回的时候检查是否可以抢占,检查的内容之一就是preempt_count是否等于0,因为禁用了下半部中断,那么肯定就不会等于0的,所以不会被抢占。也就是说返回的时候不会发生调度。

个人理解 中断上下文 最大的特征 禁掉了某种中断(硬中断和软中断),所以导致 不能阻塞。
softirq 有可能在两种方式下被调用,一是中断处理程序退出时,开放硬件中断之后,会去调用do_softirq()。 do_softirq()会禁掉后半部抢占,并且现在执行流使用的是被中断的进程的栈,所以无法阻塞。
softirq的另一种调用方式是ksoftirq内核线程,同样do_softirq()被调用,后半部中断被禁掉,同样禁止阻塞。
工作队列,可以被任何中断或者软中断中断,运行在进程上下文,有自己的栈,可以阻塞。

看一下__do_softirq()的代码,新的硬中断确实可能触发更高优先级的软中断,但是这个软中断并不会在被中断的软中断之前得到执行,软中断始终是顺序执行的。从代码看来,新一批的软中断,无论优先级多高,也得等到前一批的软中断被处理完成之后才能得到处理。而优先级只能帮助软中断在对应的批次中优先得到处理。