今天纠正了一个由来已久的认识错误：一个进程的时间片用完之后，当再次发生时钟中断时内核会调用schedule()来进行调度，把当前的进程上下文切出CPU，并把选定的下一个进程切换进来运行。我一直以为schedule()函数是在时钟中断处理函数中被调用的。其实不是，如果真是这样的话，那么在第一次这样的调度完成之后，时钟中断可能就要被mute掉了，系统从此失去“心跳”。
我之前那样理解是基于这样两点考虑：
- 在时钟中断发生时会更新进程的时间片（对于CFS调度器来说，就是更新进程的虚拟运行时间virtual run-time）。 更新完这个时间信息之后，立刻运行schedule()顺理成章，调度就应该在这个时机发生；
- 中断发生之后，（以arm架构为例）系统会从IRQ模式迅速切换成SVC模式，并且在此后的中断处理过程中，中断是关闭的，只有在切换回USR模式（其中还经过IRQ模式）时，才回再把中断打开。如果在中断处理函数中调用schedule()并不会带来中断无法再次打开的问题，因为最后总是要切换到USR模式的，那时时钟中断也总是有机会能重新打开的。
但是我没有注意到一个问题，就是ARM中断控制器(VIC)的mask/unmask操作。在进入中断响应函数之前，需要先对相应的中断设计掩码，即把正在处理的这个中断mask掉，在响应完后再把它unmask回来，好让中断能够继续发生。这段代码在kernel/irq/chip.c中（以下是经简化的示例代码）：
void handle_level_irq(unsigned int irq, struct irq_desc *desc)
{
......
mask_ack_irq(desc, irq);
......
action_ret = handle_IRQ_event(irq, action);
......
unmask_irq(desc, irq);
......
}
注：中断的mask/unmask与enable/disable是两个层次的概念：enable/disable是对所有中断而言，如果disable的话任何中断都不会发生；而mask/unmask是对一个特定的中断而言的，mask之后，指定的中断不会再发生了，但并不影响其它的中断。
所以，基于这种设计，在中断响应过程中，只能更新进程的时间片，却不可以进行调度。如果一旦在上述的handle_IRQ_event()里面调用了schedule()函数，就会立刻切换到其它进程（SVC模式，内核态），接下来的unmask_irq()执行不到，时钟中断就再也没有机会打开。切换到下一个进程之后，因为没有时钟中断，系统也就失去了心跳。
正确的方法是在中断处理快要结束时调用schedule()：
在中断处理的汇编代码中(arm架构下主要看__irq_usr)，主要的中断处理过程都完成之后，会跑到ret_to_user处准备返回用户模式。这时就会检查进程的thread_info结构中是否置有“_TIF_NEED_RESCHED”标志，如果是的话，说明需要进行进程调度，这时再调用函数schedule()。在这个时间点上，中断控制器中相应的位已经被unmask过，接下来只要开中断即可。
上面提到的汇编代码比较零散，这里就不贴了，都在文件arch/arm/kernel/entry-armv.S和entry-common.S中。