對EAST PCS系統延遲的分析與改善①

唐劍寅,肖炳甲,袁旗平

1(中國科學院 合肥物質科學研究院 等離子體物理研究所,合肥 230031)

2(中國科學技術大學,合肥 230026)

1 引言

EAST (Experimental Advanced Superconductive Tokamak)是我國自行設計研制的全超導托卡馬克裝置,目前進行周期100 μs,總時長最長1000 s的放電實驗.其等離子體控制系統PCS (Plasma Control System)負責從外部子系統獲取數據并運行控制算法,最終將結果反饋到外部系統.

1.1 EAST PCS軟硬件特性

EAST PCS在硬件平臺上,使用x86 Linux服務器作為控制進程執行環境,外部設備則使用不依賴中斷工作的輪詢設備,包括采集卡和反射內存卡.系統方面使用定制的2.6內核Linux,該系統主要通過模塊方式增加了一個屏蔽外部設備中斷的接口,供控制進程調用[1].

較短的放電周期給系統實時性提出一定要求,PCS中控制進程選擇采用循環輪詢(Polled Loop)方式運行[2],相較于中斷事件驅動型程序,這種方式采用循環等待的方式獲取資源,持續持有CPU,而非頻繁進入中斷,在PCS這類數據量大、計算任務重的快速系統中能獲得更穩定的實時能力.在放電執行階段,根據算法不同,多個相應控制進程進入實時控制狀態并行運行,簡單示例如圖1,控制進程在獲取數據時,循環讀取共享內存或反射內存卡以等待數據到來; 進行延時操作時,循環讀取TSC (Time Stamp Counter)得到當前時間,直到超時.

圖1 控制進程工作方式示例

控制進程還進行了CPU親和性設置,總是運行在特定處理器核上不發生遷移.并且采用了mlockall的方式鎖定內存,避免在運行過程中發生內存缺頁,進行處理時延誤控制進程運行.

1.2 PCS的延遲問題

循環輪詢進程期望獲得所有處理器時間,但Linux內核無法保證某個任務不受干擾地持續運行,系統噪聲成為了PCS控制進程的瓶頸.Linux系統噪聲的產生是由于系統本身為了維持正常運行,偶爾需要占用處理器一段時間,在進程中就表現為延遲[3].從系統層面而言,控制進程產生延遲的直接原因,無非是其它進程或中斷占用處理器[4].在當前100 μs控制周期下,這些延遲壓縮了控制進程數據采集、計算和傳輸的可用時間,甚至導致控制進程周期內無法完成工作,影響控制效果.而PCS還計劃采用50 μs周期控制周期,這一需求又將進一步放大噪聲影響.

1.3 國內外現狀

EAST PCS和韓國KSTAR PCS都源自美國的DIII-D PCS,三者有著類似的軟硬件特性.

DIII-D PCS目前采用CentOS 6系統,內核為2.6.32.為減少系統噪聲,DIII-D PCS使用了isolcpus內核啟動參數以避免系統自動分配任務至控制進程所在處理器,并設置了設備中斷親和性,以避免設備中斷干擾.

KSTAR PCS目前采用Scientific Linux 6系統和CERN MRG實時內核,內核版本為3.10.33,其采用實時內核主要因為使用了產生中斷的設備[5].KSTAR PCS中的控制進程采用了實時調度以避免控制進程被意外調度,并且同樣使用了內核啟動參數isolcpus.

二者對于EAST PCS進行系統噪聲改善有一定借鑒意義,尤其是實時優先級的加入和設備中斷遷移的做法值得應用.然而EAST的控制周期更短,實驗時間更長,并且三個PCS的控制進程也互有區別.EAST PCS若武斷提升控制進程為實時優先級容易導致進程阻塞等問題,并且僅僅禁止調度可能仍無法滿足控制需求.

為控制進程添加實時優先級并設法減少中斷發生是減少系統噪聲的基本思路,本文通過在PCS代碼中選擇恰當時機設置實時優先級,并進行相應系統調整,避免可能出現進程或系統阻塞問題,另外本文還通過遷移設備中斷、使用無滴答內核讓中斷發生情況得到大幅改觀,最終通過對比測試,證明了本文方法切實有效.

2 延遲改善分析

2.1 改善進程影響

EAST PCS控制進程未特別指定調度方式,其所在核上運行隊列中的進程可能帶來影響.運行隊列中的進程一般來自兩種情況:

(1) 內核為了保證系統負載均衡,會將進程分配到各個處理器核上;

(2) 內核在各個核會固定維持一些守護進程,并且不時喚醒.

由于Linux中的完全公平調度器CFS (Completely Fair Scheduler)趨向于為運行隊列中進程公平分配CPU時間[6],這兩種進程都可能導致控制進程產生被動上下文切換(involuntary context switch),從而存在延遲.

使用實時調度方式能減少控制進程受到的無關進程影響,Linux內核一般至少提供SCHED_FIFO和SCHED_RR兩種實時調度方式.采用這兩種調度方式的任務能比普通任務優先執行,并且高優先級實時任務總是能夠搶占低優先級實時任務.對于同一優先級的任務,采用SCHED_RR方式的任務會和其它任務輪流運行,而采用SCHED_FIFO的任務采用先進先出的方式運行,直到任務完全結束或者主動放棄CPU,才會允許下一個任務投入運行[7].

2.2 改善中斷影響

在Linux系統中,中斷永遠比進程優先被處理,因此實時優先級無法避免中斷帶來的延遲.

由于外部設備中斷被屏蔽,目前EAST PCS中發生最為頻繁的是本地時鐘中斷LOC (Local timer interrupt).系統利用LOC中斷進行狀態更新、信息統計、內存回收、任務調度等工作[8].LOC中斷的頻率取決于內核編譯時CONFIG_HZ的值,在EAST PCS Linux系統中 LOC中斷頻率默認為1000 HZ.

自3.10內核以后,Linux支持完全動態滴答特性(Full Dynamic ticks),即當前核上的運行隊列中不超過1個任務時,將CPU的LOC中斷設置為1 Hz[9],該特性大大降低了中斷頻率.在一些看重延遲或吞吐量的高性能計算場景中,該特性一般會被應用,以減少系統噪聲,獲得更穩定的性能[10].

完全動態滴答特性開啟后,仍會保持1 Hz的時鐘中斷滴答,用于更新vruntime、負載信息等,低精度定時任務也依賴該滴答.由于EAST PCS專用于控制,對調度的和負載信息統計的準確性及時性并不要求,因此可將1 Hz的時鐘滴答完全消除以進一步減少控制進程抖動.

3 實時調度加入

PCS采用SCHED_FIFO調度和最高實時優先級調度控制進程,以完全避免控制過程中進程切換.

PCS代碼中添加實時調度的時機有所選擇,主要因為內核對mlockall的實現,與PCS控制進程采用的循環輪詢方式存在沖突.Linux內核自2.6.28版本以后,mlockall的實現中調用了lru_add_drain_all函數,該函數負責將pagevec中的頁轉移到相應lru鏈表中,它將這一工作交給每個核上的內核工作隊列線程,并等待其執行結束.然而內核工作隊列線程并非實時優先級,會被已運行的實時循環輪詢進程阻塞,從而導致mlockall無法執行結束.因此在PCS代碼中需保證所有控制進程的mlockall執行結束,才能提升任務為實時優先級.在PCS中,控制進程的工作分為三部分,首先是設置階段,這一階段控制進程預先申請所需內存和其它資源,并且使用mlockall鎖定整個內存; 第二階段是執行階段,進行等離子體控制; 第三階段是清除階段,進行資源釋放和數據存儲[11].設置階段所有控制進程都會完成初始化,mlockall也在初始化階段調用,完成設置的進程進入輪詢狀態等待執行階段開始.若控制進程直接以實時優先級運行,最快完成內存鎖定的進程會以實時優先級持續持有CPU,其它進程的內存鎖定工作便因此阻塞.因此實時優先級的設置應當在初始化階段之后,進入執行狀態之前,才能保障進程不發生阻塞.

EAST PCS控制進程采用實時優先級后,成為實時循環輪詢進程,并在運行時希望獲得全部的CPU時間.而內核的默認配置并不保證這點,內核對實時進程的運行時間進行了限制,讓每秒中有部分時間用于普通進程.以下命令可以解除該限制[12]: echo-1 > /proc/sys/kernel/sched_rt_runtime_us

控制進程提升至實時優先級后,相應核上其它進程得不到運行,這可能導致系統無法正常工作.在3.10內核中,還需進行如下配置:

(1) 避免系統自動分配進程到相應核上.在內核啟動參數中添加”isolcpus=1–N”,N的值為處理器核數減一.這里僅保留第0個處理器核為守護核,接管非控制任務.

(2) 避免系統喚醒控制進程核上的守護進程.系統會喚醒守護進程執行日常事務活動[13],一些工作具有NUMA親和性,可能導致工作無意識地分配在非守護核上而被阻塞.在內核啟動參數中添加”numa=off”,以避免該情況.I/O可能在不同核上喚醒處理,通過以下命令進行設置,避免I/O隊列放到非守護核: echo 1 > /sys/bus/workqueue/devices/writeback/cpumask.

(3) 關閉系統檢測機制.由于放電實驗最長可至1000 s,控制進程在此期間不放棄處理器,如此長的時間會讓Linux系統中watchdog判斷系統掛起.使用如下命令關閉watchdog:

echo 0 > /proc/sys/kernel/watchdog

echo 0 > /proc/sys/kernel/nmi_watchdog

4 中斷頻率降低

PCS升級內核至3.10版本以獲得完全動態滴答特性,并更改了對外部設備中斷的處理方式.

外部設備中斷在Linux中/proc文件系統中分配了一個數字中斷號,可以通過/proc接口設置中斷對CPU的親和性,從而實現中斷遷移.更新內核后,PCS選擇將外部設備中斷遷移到守護核,而非直接屏蔽設備中斷,因此在放電實驗執行階段,控制進程所在服務器仍具備通過網絡遠程管理的能力.

為了進一步提供不受中斷影響的環境,PCS中基于Linux 3.10內核已有的完全動態滴答特性,為內核添加了新的啟動參數pcs_nohz.設置該參數后,LOC中斷頻率從1 Hz變成0 Hz,從而LOC中斷次數不再隨放電實驗時間增長而增加.

以3.10內核源代碼為例,具體修改方式如下:

(2) 在scheduler_tick_max_deferment函數中添加兩行新代碼, 修改后的函數如下:

然后確保配置CONFIG_NO_HZ_FULL=y并編譯安裝內核,在內核啟動參數中添加”nohz_full=1-N pcsnohz”并重啟,即可消除時鐘滴答.

5 延遲測試

PCS系統中直接使用匯編指令rdtsc讀取TSC來計時,使用該指令讀取時間至局部變量中僅耗費數十個指令周期,而系統的噪聲導致延遲的間隔一般遠大于此開銷.因此可以使用連續的rdtsc指令得到延遲數據,并從次數和大小兩個維度進行統計.

測試平臺配置如表1所示.

表1 測試平臺配置

測試運行時間選擇1000 s,這是目前等離子體放電的最長時間,同時,有的中斷周期或者系統檢測機制周期可能長達數百秒,1000 s一般足夠涵蓋所有可能的系統噪聲類型.

測試的內核有三個版本,分別為:

1) 2.6.32,維持PCS原來的系統配置和調度方式(屏蔽外部設備中斷,使用CFS調度),控制進程的原本運行環境;

2) 3.10,屏蔽外部設備中斷,使用CFS調度,模擬PCS直接升級內核的表現;

3) 3.10,采用實時調度,使用改善過中斷的內核,優化延遲后的控制進程運行環境.

PCS中可以忽略1 μs以下的延遲,在測試平臺上,使用連續讀取TSC的方式,測試1000 s,僅統計1 μs及以上延遲,得到結果如圖2.

從圖2中可以發現,2.6.32內核大部分延遲分布在[1,2) μs區間,隨著延遲增大,延遲發生次數逐步減少,但超過5 μs的延遲仍有相當一部分.使用3.10內核比2.6.32內核單次延遲時間出現增長,這是由于Linux在各個版本中,內核代碼變動較多,導致系統噪聲帶來的延遲并不一致,并非越新的內核就能帶來更佳效果.而按照本文的延遲優化方法,在3.10內核上,只發生3次延遲,并且所有延遲都在5 μs以內,改善十分顯著.

不進行延遲優化時,表2中≥1 μs總延遲次數在使用2.6.32和3.10內核時是類似的,結合1000 Hz的LOC中斷頻率,可以發現總延遲次數剛好和LOC中斷次數接近,這也凸顯LOC中斷對系統整體延遲的影響.不應用優化策略情況下,延遲最大值已經突破了100 μs控制周期的限制,對控制效果必然產生影響.

經過優化,控制進程的實時優先級保證其在執行階段不會發生被動上下文切換,并且無滴答的內核不再有每秒固定次數的LOC中斷打擾控制進程,這是測試結果中優化前后出現差異的主要原因.優化前后結果對比顯示本文方法能夠大幅減少延遲頻率,并且改善最壞延遲情況.PCS控制進程并非每周期中所有時間都在進行運算和數據傳輸,而是一部分時間用于標志位輪詢,這部分時間是彈性的.這實際增加了PCS對于系統噪聲的容忍度,只有系統噪聲過大或者發生在周期末尾才會導致周期超出.而優化后即使最壞情況發生,單個PCS控制進程僅僅超出周期3 μs,幾乎不對等離子體控制產生影響.

圖2 測試1000 s延遲分布情況

表2 測試1000 s延遲總體情況

6 結語

系統噪聲通常直接來自調度和中斷,會給PCS控制進程的執行帶來延遲,本文按照增加實時調度,降低中斷頻率的基本思路來改善控制進程延遲.

加入實時調度方式需要協調好實時優先級與已有代碼的關系,合理安排控制進程提升為實時任務的時機.同時還需調整系統,使之與長時間實時循環輪詢任務不沖突.

中斷的減少有多種優化方式,對外部設備中斷這類能夠直接遷移的中斷只需進行一些系統配置,而對LOC中斷則需通過修改內核代碼降低其發生頻率.

優化后的測試結果顯示,進程能感知到的最大延遲下降到3 μs左右,同時延遲次數極低.經過分析,該結果已完全符合等離子體控制需求.

在循環輪詢進程的實時性方面,本文已做到基本消除系統噪聲,但未來等離子體控制必然使用更高速的外部設備,其中一些設備可能依賴中斷工作.那時使用一款實時操作系統,并進一步改善中斷響應和進程喚醒的實時性,又將成為新的挑戰.