IO完成软中断对运行CPU的选择 - 避免一次IPI的优化

举例为对下面commit 1的翻译。而commit 1是对commit 2的revert，并加以解释。commit 1将commit 2 revert掉，可避免一个不必要的IPI中断（触发其他CPU产生软中断的IPI）。

假设前提条件：

        处理器插槽上的处理器芯片有7个cpu（cpu0~7），并假定IO请求是在cpu1上提交（__make_request）的，IO完成的硬中断是在cpu7上执行的（blk_complete_request是在IO硬中断上下文执行，其根据rq_affinity的值选择执行IO软中断的cpu）。

基于上述假设，当rq_affinity=1时：

        IO硬中断上下文会判断cpu1与cpu7是否属于同一个cpu socket， 显然cpu1,7属于同一个cpu socket（cpu1,7共享cache，即DDR内存）。有了这个commit 1，IO完成软中断将在cpu7（当前IO硬中断执行的cpu）上执行；没有commit 1对commit 2的revert时，而且因为cpu0是该cpu socket的第一个cpu，IO完成软中断将在cpu 0上执行（当前cpu7上运行的IO硬中断上下文中调用raise_blk_irq给cpu0发一个IPI中断，触发cpu0执行IO软中断）；显然有了commit 1，将会避免一个不必要的IPI中断，因为在这个例子中，cpu0,7是共享cache的，IO完成软中断在cpu0或7上执行没有本质区别，在cpu0,7上访问cache的效率是一样的。

基于上述假设，当rq_affinity=2时：

        IO完成软中断将在cpu1上执行（通过在当前cpu7上运行的IO硬中断上下文中调用raise_blk_irq给cpu1发一个IPI中断，触发cpu1执行IO软中断）。

commit 1：

 

commit 2：