schedule只负责当前cpu的任务切换吗？
请教个问题，schedule只负责当前cpu的任务切换吗？如下场景：
有2个cpu，称为core1、core2, 3个任务A、B、C，3个任务都是RT实时性任务，调度策略是SCHEDULE_FIFO，
任务A、B都绑定在core1上，B优先级高，任务C绑定在core2上；
core1：B在等待资源或者锁处于睡眠，A执行；然后，
core2：C执行，释放B需要的资源或者锁；
C在释放资源或者锁的时候，core2上会调用一次schedule，它应该只能负责core2的进程切换吧，那core1上什么时候才能由A切换到B？（假设ABC以外其他任务优先级都比这3个低）
当然~
core1上的B如果不被**的话，是不会得到调度的，因为只有RUNNING状态的进程才有机会被调度。
所以，如果需要B被重新调度，有两种方法：
1、在C释放资源时，主动wakeup B
2、B睡眠时，设个超时，比如用schedule_timeout 本帖最后由 wLiu2007 于 2014-08-13 13:35 编辑
回复 2# humjb_1983
C释放的资源或者锁是B等待的资源呀，这个跟C 直接wakeup B有什么区别吗？
个人理解无论是C释放B需要的资源、还是C主动wakeup B，core2上都会触发一次调度机会即调用schedule，这个时候只能将B的状态变成running状态，并加入到core1的rq中吧
而且这两个过程都是需要加锁的，因为在core2上的schedule代码操作core1的rq与core1上的schedule之间有竞争；
至于B能不能真正的运行需要等到core1上有调度机会，即core1上运行__schedule才可以发生真正的cpu从A切换到B，其它core最多只能改变B这个任务的状态和所在的队列？
不知道理解是否正确？
wLiu2007 发表于 2014-08-13 13:24 static/image/common/back.gif
回复 2# humjb_1983
C释放的资源或者锁是B等待的资源呀，这个跟C 直接wakeup B有什么区别吗？
呵呵，那要看B等待资源的方式，你这里没有是哪种方式~~
通常来说，比如使用信号量，那C在释放信号量时，是会主动wakeup等待在这个信号量等待队列中的进程的，但这个是信号量这种同步机制实现的，最终还是要主动wakeup的。
如果B只是简单的随眠，如果不主动**的话，那就没有调度的机会了。。。。 如果真如楼主所说, 那不是有的CPU累shi了, 有的饿shi了? :mrgreen: 回复 5# q1208c
看了一下调度的代码，貌似我说的是对的，只不过core2设置进程B的running状态，加入core1的runqueue之后，并且会设置B的resched标志，
然后core2再给core1发一个中断信号smp_send_reschedule(cpu);这样就会触发core1的调度机会，这样就能够从A切到B；
本帖最后由 Tinnal 于 2014-08-13 21:06 编辑
回复 6# wLiu2007
嗯，你确实看代码了，呵呵。理解的也是对的。但有两点要注意的：
1. 以上的讨论只在没有发生核迁移的情况。
2. 因此你三个进程采用的都是FIFO，因此如果A不主动睡眠，就算B已经被“唤”“醒”，B还是没有机会运行的（还是基于没有迁移的情况），除非你改为RR算法。
“唤”“醒”也敏感？晕。 Tinnal 发表于 2014-08-13 21:04 static/image/common/back.gif
回复 6# wLiu2007
嗯，你确实看代码了，呵呵。理解的也是对的。但有两点要注意的：
楼上你俩所言甚是！ 回复 7# Tinnal
我这里已经假设了，A、B都是schedule_fifo，且B的优先级比A高，有亲和设置，不会发生迁移，所以只要core2给core1发送了中断通知，core1有了调度机会，就能够马上从A切到B
Tinny兄，**也敏感，什么意思哟？
看到**，我知道啥意思呢 呵呵
页:
[1]
2