关于SMP多核CPU调度器工作原理的疑问

Huntsmen

之前接触的都是基于单核的嵌入式操作系统，建立的概念是任务调度器schedule在时间片定时器中断、中断返回、任务发消息时会被调用。
现在有了多核以后，有几个疑问：以4核举例
1，中断响应应该在哪个核上面执行，schedule是在哪个核上运行的，有固定的核吗？
2，cpu0上task A发了一个消息会触发scheduler，这个时候cpu 1上的task B也发了一个消息，也会去调用scheduler吗？这个时候是不是有竞争，需要做保护？
3，假设当前schedule在cpu0上运行，调度结果发现cpu0、cpu1的task都需要切换（因为有高优先级的任务），比如cpu0要从task A切到task B，cpu1要从Task C切到Task D，那cpu0的切换好说，因为在schedule就运行在cpu0上，直接将cpu0的pc从task A指到task B就可以了，关键cpu1的切换怎么做，cpu0肯定不能去修改cpu1的pc值，cpu1的pc是怎么从task C变成task D的
4，schedule运行在cpu0上，那它是怎么知道另外3个cpu的负载情况的？怎么知道别的cpu上有没有在做事情？

希望得到大牛的指点，谢谢

瀚海书香

回复 1# Huntsmen

之前接触的都是基于单核的嵌入式操作系统，建立的概念是任务调度器schedule在时间片定时器中断、中断返回、任务发消息时会被调用。
现在有了多核以后，有几个疑问：以4核举例
1，中断响应应该在哪个核上面执行，schedule是在哪个核上运行的，有固定的核吗？
2，cpu0上task A发了一个消息会触发scheduler，这个时候cpu 1上的task B也发了一个消息，也会去调用scheduler吗？这个时候是不是有竞争，需要做保护？
3，假设当前schedule在cpu0上运行，调度结果发现cpu0、cpu1的task都需要切换（因为有高优先级的任务），比如cpu0要从task A切到task B，cpu1要从Task C切到Task D，那cpu0的切换好说，因为在schedule就运行在cpu0上，直接将cpu0的pc从task A指到task B就可以了，关键cpu1的切换怎么做，cpu0肯定不能去修改cpu1的pc值，cpu1的pc是怎么从task C变成task D的
4，schedule运行在cpu0上，那它是怎么知道另外3个cpu的负载情况的？怎么知道别的cpu上有没有在做事情？

中断响应不再固定的核上，也可以指定在固定的核上。每一个进程都是调度的主体，所以schedule会运行在任何一个核心上。调度常见发送的地方如进程因为IO阻塞主动调用schedule、scheduler_tick定时检查当前进程的时间片是否需要调度等。

不同的CPU调度属于自己CPU的队列，当不均衡的情况下会从别的CPU核心上迁移进程到本地CPU上调度。这个过程需要锁的保护，而且为了防止死锁，约定获取cpu的调度锁的时候，必须从小到大。比如当前进程持有2号CPU锁，那么这个进程可以直接获取3号CPU锁，要想获取1号CPU锁，必须先释放2号CPU锁。


   

Huntsmen

感谢瀚海书香 大侠的回复。
是不是可以这么理解：
是不是可以这里理解，如果有多个cpu同时触发了调度，他们都会调用schedule，多个schedule会同时在运行，在不发生进程迁移的时候，不需要加锁，因为各个cpu只会调度自己cpu上的进程。

另外有个问题想请教：
当不均衡的情况下会从别的CPU核心上迁移进程到本地CPU上调度。
这个不均衡的是由谁在监测的，迁移过程是怎样的？能说个大概的思路吗

非常感谢！

Huntsmen

顶起来，别沉了

灌水菜鸟

你对SMP的概念可能有点模糊。所谓内核无非就是一个超级大的指令序列，每个CPU跑的都是这个超级指令序列而已。所以不存在scheduler跑在哪个核上的问题，应该是每个CPU都要调度，都使用相同的调度器。

xs3c

回复 1# Huntsmen


    1，中断响应应该在哪个核上面执行，schedule是在哪个核上运行的，有固定的核吗？

对与不同的arch中断有所不同，对于PPC为例，对于Linux的时钟中断，是用的DEC异常，这个是每个核都有一个，另外在说外部中断，完全取决中断控制器，还是以PPC的 MPIC控制器为例，开始外部中断都是报给CPU0，当然每个外部中断都有affinity， 通过这个你可以固定中断报给具体CPU。

2，cpu0上task A发了一个消息会触发scheduler，这个时候cpu 1上的task B也发了一个消息，也会去调用scheduler吗？这个时候是不是有竞争，需要做保护？

假设你说的scheduler，是一般嵌入式操作系统里面，context_switch，因为是每个线程都有kernel stack，所以单从context switch里说不需要保护，
3，假设当前schedule在cpu0上运行，调度结果发现cpu0、cpu1的task都需要切换（因为有高优先级的任务），

对于linux 来讲，每次调度的应该只从当前CPU的run quenue来取进程，如CPU1有高优先级进程，CPU1会处理。
比如cpu0要从task A切到task B，cpu1要从Task C切到Task D，那cpu0的切换好说，因为在schedule就运行在cpu0上，直接将cpu0的pc从task A指到task B就可以了，关键cpu1的切换怎么做，cpu0肯定不能去修改cpu1的pc值，cpu1的pc是怎么从task C变成task D的
4，schedule运行在cpu0上，那它是怎么知道另外3个cpu的负载情况的？怎么知道别的cpu上有没有在做事情？

每个schedule domain里面应该会有字段的信息，具体就要看load_balance函数了。

arm-linux-gcc

中断可以设置affinity，arm里面affinity默认是所有的core都可以响应，
由于isr处理通常很快，所以绝大部分时间core 0都是可以响应中断的，所以绝大部分的中断都会由core 0来响应，这样一来core 0上的app就被频繁的打断，这样core 0上的app的性能就低于其他core的app的性能了，所以需要将某些比较频繁的中断单独绑定到core 1上

如果不单独设置affinity到core 1上，那么就只能是在core 0处理某个中断的isr时，中断才会迁移到core 1上
这几率是很低的