內(nèi)容簡介

本文主要討論在高實時要求、高效能計算、DPDK等領(lǐng)域，Linux如何讓某一個線程排他性獨占CPU；獨占CPU涉及的線程、中斷隔離原理；以及如何在排他性獨占的情況下，甚至讓系統(tǒng)的timer tick也不打斷獨占任務，從而實現(xiàn)最低的延遲抖動。

工程需求

在一個SMP或者NUMA系統(tǒng)中，CPU的數(shù)量大于1。在工程中，我們有時候有一種需求，就是讓某個能夠獨占CPU，這個CPU什么都不做，就只做指定的任務，從而獲得低延遲、高實時的好處。

比如在DPDK中，通過設置

GRUB_CMDLINE_LINUX_DEFAULT=“isolcpus=0-3,5,7”

隔離CPU0,3,5,7，讓DPDK的任務在運行的時候，其他任務不會和DPDK的任務進行上下文切換，從而保證網(wǎng)絡性能最佳[1]。在Realtime應用場景中，通過isolcpus=2隔離CPU2，然后把實時應用通過taskset綁定到隔離的核：

taskset-c 2 pn_dev

從而保證低延遲要求[2]。

Part 2

用戶態(tài)隔離

這個地方，我們可以看出，它們統(tǒng)一都使用了isolcpus這樣一個啟動參數(shù)。

實踐是檢驗真理的唯一標準，下面我們來啟動一個8核的ARM64系統(tǒng)，運行Ubuntu，并指定isolcpus=2這個啟動參數(shù)：

系統(tǒng)啟動后，我們運行下面簡單的程序（啟動8個進程運行while死循環(huán)）:

我們是8核的，現(xiàn)在又是運行8個進程，所以理論上來講，負載均衡后，8個進程應該均分地運行在8個核上面，但是我們來看看實際的htop結(jié)果：

我們發(fā)現(xiàn)3（也就是CPU2）上面的CPU占用率是0.0%。這實證了CPU2已經(jīng)被隔離，用戶空間的進程不能在它上面跑。

當然，這個時候，我們可以通過taskset，強行把其中的一個a.out，綁定到CPU2上面去：

從上面命令的結(jié)果看出，663原本的affinity list只有0,1,3-7是沒有2的，而我們強行把它設置為了2，之后再看htop，CPU2上面占用100%：

通過上面的實驗，我們明顯可以看出isolcpus=2使得CPU2上無法再運行用戶空間的進程了（除非手動設置affinity）。

Part 3

內(nèi)核態(tài)隔離

中斷

但是，能在CPU2上面運行的，不是只有用戶態(tài)的任務，還可以有內(nèi)核線程、中斷等，那么isolcpus=能否隔離內(nèi)核線程和中斷呢？

對于中斷，我們特別容易查看，就是實際去驗證每個IRQ的smp_affinity就好了：

從上圖明顯可以看出，對于44、47號這種外設的中斷，Linux內(nèi)核把smp_affinity設置為了FB（11111011），明顯避開了CPU2，所以，實際外設中斷也不會在CPU2發(fā)生，除非我們強行給中斷綁核，比如讓44號中斷綁定到CPU2：

echo 2 >/proc/irq/44/smp_affinity_list

之后，我們發(fā)現(xiàn)44號中斷在CPU2可以發(fā)生：

但是，系統(tǒng)的timer中斷、IPI，由于是Linux系統(tǒng)的運行基石，實際還是要在CPU2上面運行的。這里面最可能給任務帶來延遲抖動的，自然是timer tick。

下面我們重點探討下tick的問題，由于Linux一般情況下，已經(jīng)配置IDLE狀態(tài)的NO_HZ tickless，所以CPU2上面什么都不跑的時候，實際timer中斷幾乎不發(fā)生。

下面，我們還是在isolcpus=2的情況下，運行前面那個8個進程的a.out，默認情況下沒有任務會占用CPU2。通過先后運行幾次cat /proc/interrupts | head 2，我們會看到其他core的timer中斷頻繁發(fā)生，而CPU2幾乎不變，這顯然是IDLE時候的NO_HZ在發(fā)揮省電的作用：

但是，一旦我們放任務到CPU2，哪怕只是放1個，就會發(fā)現(xiàn)CPU2上面的timer中斷開始增加：

這說明一點，哪怕隔離的CPU上面只有一個線程去跑，timer tick就會開始跑，當然，這個timer tick也會頻繁打斷這一個線程，從而造成大量的上下文切換。你肯定會覺得Linux怎么這么傻，既然只有一個人，那也沒有時間片分片的必要，不需要在2個或者多個任務進行時間片劃分地調(diào)度，為啥還要跑tick？其實原因是我們的內(nèi)核默認只是使能了IDLE的NO_HZ：

我們來重新編譯一個內(nèi)核，使能NO_HZ_FULL：

當我們使能了NO_HZ_FULL后，Linux支持在CPU上僅有1個任務的時候，是可以NO_HZ的。但是有2個就傻眼了，所以這個“FULL”也不是真地FULL[3]。這當然也可以理解，因為有2個就涉及到時間片調(diào)度的問題。什么時候應該使能NO_HZ_FULL，內(nèi)核文檔Documentation/timers/no_hz.rst有明確地“指示”，只有在實時和HPC等的場景，才需要，否則默認的NO_HZ_IDLE是你最好的選擇：

我們重新編譯了內(nèi)核，選中了NO_HZ_FULL，下面啟動Linux，注意啟動的時候參數(shù)添加nohz_full=2，讓CPU2支持NO_HZ_FULL：

重新運行CPU2只有一個任務的場景，看看它的timer中斷發(fā)生情況：

發(fā)現(xiàn)CPU2上面的tick穩(wěn)定在188上面，這樣相信你會更加開心，因為你獨占地更加徹底了！

下面，我們再放一個task進去CPU2，有2個任務的情況下，CPU2上面的timer tick開始增加：

不過，這或許不是個問題，因為我們說好了“獨占”，1個任務獨占的時候，timer tick不來打擾，應該已經(jīng)是非常理想的情況了！

內(nèi)核態(tài)線程

內(nèi)核態(tài)的線程其實和用戶態(tài)差不多，當它們沒有綁定到隔離的CPU的時候，是不會跑到隔離CPU運行的。下面用筆者在內(nèi)核里面添加的dma_map_benchmark來做實驗[4]，開啟16個內(nèi)核線程來進行DMA map和unmap（注意我們只有8個核）:

./dma_map_benchmark -s 120 -t 16

我們看到CPU2上面的CPU占用也是0：

內(nèi)核里面的dma_map_benchmark線程在狂占CPU0-1, 3-7，但是就是不去占CPU2：

但是，內(nèi)核線程如果用kthread_bind_mask()類似API把線程綁定到了隔離的CPU，則情況就不一樣了，這就類似用taskset把用戶態(tài)的任務綁定到CPU一樣。

Part 4

最佳實踐指南

對于實時性要求高、高性能計算等場景，如果要讓某個任務獨占CPU，最理想的選擇是：

1.采用isolcpus隔離CPU

2.將指定任務綁定到隔離CPU

3.小心意外地把中斷、內(nèi)核線程綁定到了隔離CPU，排查到這些“意外”分子

4.使能NO_HZ_FULL，則效果更佳，因為連timer tick中斷也不打擾你了。

審核編輯：湯梓紅