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