SMP系统，被唤醒的进程是否一定在当前cpu上运行？

vsoloo

目前发现在SMP上，网络报文处理 都在同一个 cpu A 上进行，另一个 cpu B 未参与。

我所知道的是，网络报文 在两个地方处理：
    1. 硬中断退出末尾的软中断的直接调用，处理了部分网络报文。由于多 CPU 硬件上设计为 网卡 硬中断总是触发 cpu A 来处理，所以这部分 处理总是在 cpu A 执行，这个可以理解；
    2. 在某些时刻 唤醒 softirqd 内核线程来处理 1 中未来的及处理的网络报文，那么即使 总是由 cpu A 来实施唤醒 softirqd 的操作，linux 会保证被唤醒的softirqd 仍然在 cpu A 上执行吗？即 “被唤醒的进程是否一定在当前cpu上运行？”  否则是什么原因致使 网络报文 都由 cpu A 处理的？

vsoloo

题目写歪了，显然是不成立的
又大致分析了下网络收发包的流程，网络收发包 做到 CPU 绑定还是有可能的

前提：
    a.网络收发包 由软中断处理函数 do_softirq 中 NET_TX_SOFTIRQ 和 NET_RX_SOFTIRQ 部分负责；
    b.软中断处理函数 do_softirq 基于 __softirq_pending 位的，而 __softirq_pending 位是每 CPU 变量；
    c.__softirq_pending 位 的 set 操作在 硬中断 或者 软中断处理函数 do_softirq 中，且第一个 set 操作应该是在 硬中断 中；  
    d.ksoftirq 是 每 CPU 的；
   
基于以上前提，对于网络报文处理而言，若将 网卡硬中断 在硬件上设计为与 CPU 绑定的，则：
    1.由于 收发硬中断 在硬件上设计为 CPU 绑定的，故 由 硬中断 set 的 __softirq_pending 位 是 CPU 绑定的
    2.基于 1 ，硬中断末尾调用的 软中断处理函数 do_softirq（包括唤醒 ksoftirq）的网络收发包部分 是 CPU 绑定的
    3.基于 1 和 2，由 软中断处理函数 do_softirq（包括ksoftirq的 do_softirq） set 的 __softirq_pending 位 也是 CPU 绑定的
    4.基于 __softirq_pending 位 的软中断处理函数 do_softirq（包括ksoftirq的 do_softirq）的网络收发包部分是 CPU 绑定的
    5.网络收发包 是 CPU 绑定的
       
       
在大吞吐量时，查看 CPU0 和 CPU1 的 ksoftirq 的调度状态可以得到验证：       
# cat /proc/7/schedstat
460444000000 28146000000 14218
# cat /proc/18/schedstat
1000000 0 41