中断返回与调度救助

humjb_1983

看似有点乱，呵呵~

中断返回是进程调度的一个时机点，这两者并非并列的概念。进程调度通常发生在：
1、中断、异常、系统调用返回处。
2、wakeup和手工调用schedule的地方
其中中断返回时，进行系统调度，是进程调度发生最频繁的地方，因为调度主要依赖于时钟中断(一般来说哈)。具体的代码可以看看entry_xx.S汇编代码。

"中断处理的一般步骤为：保存cpu寄存器 和 堆栈等--->切换到中断处理--->中断处理完成--->恢复cpu环境
那么这个恢复cpu环境的过程，有没有可能发生cpu的切换。又是如何控制的？"
--- 这个应该是不会发生CPU切换的，也就是说中断处理过程中不会切换CPU(准确的说应该是迁移)。

”比如软中断一般的理解是“谁触发，谁执行”，就是说软中断执行过程中不会跨cpu。而开启smp的同个进程，却又是可以跨cpu的。
那么针对软中断 和 进程 被中断后的恢复，是否可能发生cpu的切换？“
--- 首先软中断确实是“谁触发，谁执行”，所以软中断通常不会发生CPU迁移；进程在被中断后，在中断返回时，有一个调度的时机点，如果此时没发生调度，则返回原进程上下文执行，此时应该也不会迁移CPU；如果此时发生调度，则调度其它进程到当前CPU运行，则原来的进程暂停运行，此时通常也不会迁移到其它CPU，除非有特殊的情况(如：cpu负载均衡将其拉倒其它CPU)。

”还有针对以上问题。调度又是如何处理的。现在一般都是 抢占式内核
那么如果进程a 被进程b给打断，也是  保存cpu寄存器 和 堆栈等--->切换到进程b--->进程b完成，重新调度--->恢复cpu环境
这种流程吗。应该不对吧。感觉很奇怪“
--- 刚才说的中断返回只是调度的一个时机点，不是并行的概念。抢占式内核比普通内核来说，只能调度的时机点更多，但主要还是要依赖中断返回，所以这里”进程a 被进程b给打断“说法不对，b进程不能直接打断a进程，能打断a进程的只能是中断或异常等情况，然后待中断/异常返回时，进行调度，调度时检查是否开启了抢占，如果开启，则能在内核态发生调度。

”还有中说法是，系统堆栈是 per cpu结构。所以从这个理解，中断返回后，中断前的环境肯定只能恢复到原来的cpu上
而这种说法同时认为 cpu的负载均衡，是通过调度器拉实现的。那么这种拉 指的是per cpu变量的copy 和 删除吗？“
--- 这里的”系统堆栈“说法也不准确，应该是说的中断栈吧？中断栈的确是per cpu的，但内核栈和用户栈是per task的，因为Linux中对中断进行了串行话处理，所以中断通常不会嵌套，所以per cpu的中断栈应该不会有问题。中断返回后会切换到进程的内核栈，而内核栈是per task的，上下文也是独立的，所以被中断的进程理论上是可以被拉到其它CPU上运行的(通常不会)。

请参考：
http://blog.chinaunix.net/uid-14528823-id-4739291.html
http://blog.chinaunix.net/uid-14528823-id-4740294.html

humjb_1983

anyhit 发表于 2015-01-06 19:53
回复 2# humjb_1983
多谢83兄的指导。说的很明白。尤其是per task栈的概念，以前完全没这个概念。所以总是 ...

每个CPU的调度是相对独立运转的，每个cpu都有自己的调度队列，当某task在某CPU上运行后，该task就位于该CPU相应的调度队列中了，在没有特别情况时(如需要负载均衡)，该task应该一直在该CPU上运行的。