进程A在CPU0上，CPU占用率99%；进程B在CPU1上，占用率20%，为何进程B还会被调度到CPU0

wyyzxml

你的这个问题设置亲和没有用吧。
如果A进程也跑到CPU1上来了，那还是会同样出现这个问题。

你可以修改进程A的内核驱动，当其占用CPU太久的时候，就放弃占用CPU

almeydifer

我怀疑是不是内核开了什么节能的选项？

lofeng410

回复 12# almeydifer

没有开启节能的，这个很确定
   

linuxhunter

1、由于进程A进入内核态后使用了spin_lock，因此关闭了内核抢占，所以B只有在A从内核态返回到用户态时才能抢占执行；
2、B是实时进程采用实时调度器类，而A是普通进程采用CFS调度器类。在进程A和进程B同时做为用户态进程时，当B有请求调度时，调度器一定会让B执行，因为实时调度器类优先于CFS调度器类；
3、由于进程A和进程B采用不同的调度器进行调度，因此CFS调度器类中的load_balance不会对实时进程B有效，同时实时调度器类中的load_balance不会对普通进程A有效；
4、可行的办法是将进程A和进程B分别绑定到不同的CPU上，这样可以从根本上解决这个问题。另外一个解决方法是将进程A和进程B采用相同的调度器，这样调度器的load_balance会均衡CPU运行队列的权重；

leslielg

回复 15# linuxhunter


    如果B不被放到cpu0上运行，这个spin_lock就对它没有影响了，楼主问的就是为何它会被调度到cpu0上去等这个spin_lock。

另外这么慢速的外设访问，为何不用dma？怎么会把所有操作都包在spin_lock里？只需要把部分互斥的操作用spin_lock保护就行了，不能长时间禁止调度器，spin_lock就是因为开销小所以才在一些很短的代码用它。或者换用mutex，semaphore。

justlinux2010

可以安装schedutils包，然后使用taskset命令将进程绑定到指定的CPU上，可以采取不同的绑定策略。具体网上教程很多，搜索一下

titer1

这个一针见血，为何不考虑其他同步手段？