rq_affinity， 块设备IO完成软中断的平衡
By default this value is set to 1, which means that once an I/O request has been completed by the block device, it will be sent back to the "group" of CPUs that the request came from. This can sometimes help to improve CPU performance due to caching on the CPU, which requires less cycles. If this value is set to 2, the block device will sent the completed request back to the actual CPU that requested it, not to the general group. If you have a beefy CPU and really want to utilize ALL THE CORES and spread the load around as much as possible then a value of 2 might provide better results.
echo 2 > /sys/block/sda/queue/rq_affinity
To make this a permanent change we will add it to /etc/rc.local
vim /etc/rc.local
##Add this above "exit 0"##
echo 0 > /sys/block/sda/queue/add_random
echo 0 > /sys/block/sda/queue/rotational
echo 2 > /sys/block/sda/queue/rq_affinity exit 0
#rq_affinity = 2，将IO完成的软中断调度到等待IO返回的进程的cpu核心上(即调用__make_request提交IO request时的进程运行的CPU)。
PATCH:
Commit 5757a6d76c introduced a new rq_affinity = 2
某些系统会受益于IO完成的软中断在提交IO的CPU上运行，而不是IO完成的软中断松散的绑定在一个CPU socket上(per-scoket就是上面的cpu-Group，A CPU socket is a mount on a computer motherboard that accepts a CPU chip，一个CPU芯片包含多个CPU处理核心）。这是因为如果绑定在一个CPU的socket上，CPU scoket上的第一个CPU核心就会超负荷工作，而socket中的其他CPU核心比较空闲。
当rq_affinity=2时，哪个CPU提交的IO，哪个CPU负责处理该IO的完成软中断，这样所有IO的完成软中断整体上就会分散到所有的CPU上，正如上面所说的一样: utilize ALL THE CORES and spread the load around as much as possible then a value of 2 might provide better results
代码（4.14内核）：
”echo 2 > /sys/block/sda/queue/rq_affinity“ 这样设置时，块设备sda的request_queue的queue_flags设置上了QUEUE_FLAG_SAME_COMP, QUEUE_FLAG_SAME_FORCE. 在选择IO完成软中断所要运行的CPU时会判断queue_flags.
IO完成流程：
IO完成硬中断(如megaraid-sas)
->scsi_done(仍在IO完成硬中断上下文运行)
->blk_complete_request(同上)
->__blk_complete_request(同上), 触发IO完成软中断
如上述代码，有以下逻辑：
1，如果设置了COMP而没有设置FORCE(rq_affinity=1)：
1）并且提交IO的CPU(req->cpu)与当前执行IO完成硬中断的CPU共享cache（shared=true，即两个CPU属于同一个CPU socket内部的不同核心），则可以在当前CPU内执行IO完成软中断；
2）并且提交IO的CPU(req->cpu)与当前执行IO完成硬中断的CPU不共享cache（shared=false）：
（1）但提交IO的CPU(req->cpu)与当前执行IO完成硬中断的CPU时同一个，则可以在当前CPU内执行IO完成软中断；
（2）但提交IO的CPU(req->cpu)与当前执行IO完成硬中断的CPU时不是同一个，就给IO提交CPU触发一个BLK软中断。
2，如果设置了COMP且设置了FORCE(rq_affinity=2)：
1）但提交IO的CPU(req->cpu)与当前执行IO完成硬中断的CPU时同一个，则可以在当前CPU内执行IO完成软中断；
2）但提交IO的CPU(req->cpu)与当前执行IO完成硬中断的CPU时不是同一个，就给IO提交CPU触发一个BLK软中断。
3，如果没有设置COMP(rq_affinity=0)，则：
在cpu-Group内执行IO软中断。
在当前CPU内执行IO软中断的逻辑：
如果IO完成list中只有刚才添加的req，就触发一个软中断处理，如果不止刚添加的req，说明前面已经触发了BLK软中断（还是这个上述代码设置的，未执行可能是被硬中断打断），就不再触发软中断，等待已经触发的软中断运行时一起处理刚添加的req（list中有至少两个req了）。
软中断处理函数如下：
向触发远程CPU触发IO完成软中断：
默认值：
参考：
1，https://wiki.mikejung.biz/Ubuntu_Performance_Tuning
2，What is a CPU Socket? https://www.wisegeek.com/what-is-a-cpu-socket.htm#didyouknowout