通用非對稱多核方案設計
隨著摩爾定律的終結, 多核處理器和平行計算得到大量關注, 多核平行計算技術因為能充分利用當前計算機系統的計算能力, 同時降低成本和功耗[1-3], 提升產品競爭力, 是當前的熱點應用技術. 但目前多核處理器較少應用於實時系統, 這是因為實時系統要求任務的執行時間不能超過截止期, 而相對於單核處理器而言, 多核處理器在訪問硬體共享資源(如Cache、內部互聯匯流排、記憶體等)時產生競爭干擾, 很難獲得任務安全、準確的最壞情況執行時間, 這就要求處理器體系結構設計能給出確定性的實時性預估結果[4].
微機保護測控裝置是對電力系統內一次裝置進行監察、測量、控制、保護、調節的輔助裝置[5], 其中電氣量採集分析、保護控制訊號響應等功能有硬實時性要求, 而螢幕顯示、鍵盤輸入、列印、網路通訊等功能對實時性要求不高, 但希望軟體功能豐富, 硬體覆蓋全面[
現有的AMP硬體設計方案中, 以異構處理器和Xilinx Zynq-7000處理器為主. 異構處理器多是CPU+DSP結構[11-13],其中CPU執行非實時任務, DSP執行實時任務. Xilinx Zynq-7000是一款雙核CPU+FPGA結構的SoC晶片, 其中CPU0執行非實時任務, CPU1執行實時任務[14-16]. Xilinx Zynq-7000 針對AMP應用場景做了諸多晶片設計優化, 並開發了OpenAMP軟體開發框架[17].
現有的AMP軟體設計方案中, 以MCAPI (Multicore Communications API)和OpenAMP框架為主. MCAPI是一個輕量級開源多核通訊框架, 支援基於訊息傳遞形式的嵌入式多核通訊核同步程式設計[
MCAPI缺少從核CPU的生命週期管理功能, OpenAMP缺少對通用處理器的支援. 針對上述問題, 本文提出一種基於通用多核處理器的AMP解決方案, 並重點討論了AMP軟體總體設計、共享資源管理方法和核心模組設計.
1 AMP軟體總體設計
AMP軟體總體模組框圖如圖1所示, 分為AMP啟動和AMP通訊兩個子系統. AMP啟動子系統由使用者態模組amprun和核心態模組amproc實現, 負責AMP從核的程式載入、啟動、停止、重啟等功能. AMP通訊子系統由使用者態模組ampcomm和核心態模組ampeth實現, 負責AMP核間網路通訊. 核心態模組amproc主要實現AMP從核的控制管理, 通過sysfs匯出使用者態訪問介面給使用者態模組amprun使用; 核心態模組ampeth在Linux網路子系統和Linux核間中斷子系統之上, 基於共享記憶體和核間中斷, 實現一個虛擬網口, 提供給使用者態模組ampcomm實現AMP核間的套接字網路通訊.
與OpenAMP相比, 本方案對作業系統元件依賴少, 沒有硬體依賴, 為快速適配到不同的通用處理器和作業系統創造了有利條件. 與MCAPI相比, 本方案增加了從核CPU的生命週期管理功能, 功能更加全面. 本方案的核間通訊採用網路通訊機制, 是OpenAMP和MCAPI都不支援的. 核間網路通訊的缺點是實時精度不高, 但滿足繼電保護裝置的分散式板卡通訊效能要求, 而且有豐富的網路應用服務支撐和相容當前基於網路通訊的分散式系統架構等優點.
圖1AMP軟體模組框圖
2 共享資源管理
多核處理器中, 除了CPU核心、L1 Cache、TLB、MMU等少數模組是每個CPU的私有資源外, 其他硬體資源都是CPU共享資源, 如Last Level Cache、片內互聯匯流排、記憶體、外設等. 當硬實時任務在同時訪問這些共享資源時, 就會發生資源訪問衝突, 給硬實時任務帶來不可預測的額外執行時間. 為了避免訪問衝突, 需要對所有共享資源進行劃分和管理.
2.1 記憶體
在各類共享資源中, 對系統性能影響最大的是共享記憶體和Cache, 為了緩解這一問題, 除了增加可用共享資源外, 公平高效地管理和利用共享記憶體資源至關重要[20]. 基於通用考慮, AMP通訊功能基於共享記憶體實現. 記憶體劃分為三部分, 即共享記憶體區、Linux記憶體區和RTOS記憶體區, 如圖2所示.
圖2記憶體劃分圖
共享記憶體區位於記憶體頭部, 方便Linux記憶體區和RTOS記憶體區的擴充套件. 共享記憶體由Linux初始化, Linux和RTOS共同使用. 共享記憶體區內部劃分為多個段, 在AMP驅動載入時按需動態申請, 段資訊由共享記憶體區頭header維護, 其中包括RTOS的環境變數env、RTOS的啟動引數段cmdline、AMP從核執行狀態amproc.stat、AMP核間通訊網路狀態ampeth.stat、AMP核間通訊網路傳送快取ampeth.tx、AMP核間通訊網路接收快取ampeth.rx等.
不同的記憶體區設定不同的記憶體屬性, 其中共享記憶體的記憶體屬性設定為non-cacheable, 避免單次資料佔用快取資源; Linux記憶體區和RTOS記憶體區的記憶體屬性設定為non-shareable, 避免cache/TLB一致性維護在核間廣播, 擠佔內部互連匯流排頻寬資源, 影響CPU效能.
2.2 外設
根據AMP主核和從核的不同功能定位, 將除記憶體之外的所有外設分別分配給AMP主核或從核使用, 儘量保證主核和從核上的外設在不同的總線上, 避免外設匯流排訪問競爭.
2.3 處理器
AMP從核工作模式設定為AMP模式, 保證AMP從核不會發送和接受cache/TLB的一致性維護廣播, 有利於提升AMP從核的實時性.
2.4 Cache快取
AMP從核關閉Last Level Cache, 保證AMP從核能獲得可靠的任務最壞情況執行時間, 避免因為AMP主核任務汙染Last Level Cache 而造成AMP從核任務執行時間的抖動和惡化. Last Level Cache由AMP主核控制和使用. 如果AMP從核希望對L2 Cache進行重新整理、無效等操作, 需要通知AMP主核, 由主核進行操作.
2.5 片內匯流排
多核處理器大都在互聯結構中集成了控制多核之間優先順序的匯流排仲裁功能, 可以在啟動AMP從核的同時設定相應優先順序.
如果處理器缺少控制多核之間優先順序的匯流排仲裁功能, 為了保證實時任務的實時計算, AMP主核上的軟體需要精心設計, 避免長時間的匯流排訪問風暴, 大量的匯流排衝突導致訪問佇列迅速增長, 延遲加劇, 造成AMP從核實時任務超時.
3 AMP軟體功能設計
3.1 AMP從核映象載入
AMP從核執行實時系統需要載入的映象檔案包括RTOS映象、配置檔案config、環境變數env和啟動引數cmdline四部分.
RTOS映象、配置檔案config採用FIT(Flattened Image Tree)格式打包, amprun模組根據FIT映象中的屬性資訊如檔案列表、壓縮格式、校驗演算法、載入地址等, 負責解析、校驗、解壓、載入到RTOS記憶體區.
環境變數env儲存在nor flash上, 而nor flash由AMP主核控制, 所以需要amprun模組從nor flash中讀出環境變數, 並寫入共享記憶體區的環境變數env段, 以便AMP從核啟動時使用.
為了靈活控制RTOS的啟動模式和功能等, 啟動引數cmdline需要根據使用者輸入動態生成, 所以amprun模組根據使用者輸入動態生成cmdline, 並寫入共享記憶體區的啟動引數cmdline段.
3.2 AMP從核啟動
完成AMP從核映象載入後, amprun模組使用amproc模組提供的介面, 完成AMP從核的啟動、停止、重啟等生命週期的控制管理.
啟動AMP從核操作過程如下:
- 初始化AMP從核執行狀態stat;
- 禁止CPU本地中斷;
- 記憶體屏障;
- 重新整理L1 和L2 Cache(PoU);
- 通知其他所有SMP CPU 等待AMP從核完成啟動(方法與步驟(11)相同);
- 設定CPU軟體復位啟動地址暫存器為AMP從核RTOS映象的入口地址;
- 復位AMP從核;
- 復位AMP 從核的L1 Cache;
- 禁止AMP 從核的外部除錯訪問;
- 解復位AMP從核, AMP從核啟動;
- 迴圈檢查AMP從核執行狀態stat, 等待AMP從核完成啟動. (AMP從核完成啟動後會更新amproc.stat);
- 使能CPU本地中斷;
停止AMP從核操作過程如下:
- 復位AMP從核;
- 禁止AMP 從核的外部除錯訪問;
- 下電AMP 從核;
- 初始化AMP從核執行狀態stat;
3.3 AMP核間通訊
AMP核間通訊通過虛擬網路介面, 其基於共享記憶體和核間中斷實現. 共享記憶體段中的ampeth.stat、ampeth.tx、ampeth.rx用於AMP核間通訊. ampeth.tx、ampeth.rx共享記憶體段結構相同, 由64個緩衝區描述符物件(Buffer Descriptor, BD)組成. 每個BD由有效狀態valid、幀長len和幀資料區data三部分組成. ampeth.tx對於AMP主核是傳送緩衝區, 對於AMP從核是接收緩衝區; ampeth.rx對於AMP主核是接收緩衝區, 對於AMP從核是傳送緩衝區. ampeth.stat共享記憶體段由傳送緩衝區描述符物件頭索引tx_idx和傳送緩衝區描述符物件頭索引rx_idx組成, 用於tx_idx和rx_idx在主從核間的同步.
AMP核間通訊虛擬網口的傳送流程如圖3所示. 首先檢查當前傳送BD是否空閒, 如果非空閒, 說明整個傳送快取已沒有可用的空閒BD, 丟棄傳送幀並退出. 如果當前BD空閒, 檢查傳送幀長度是否超過BD資料區長度, 如果超出, 丟棄傳送幀並退出. 當所有檢查都通過後, 將傳送幀資料拷貝到當前傳送BD的資料區, 並將當前BD設定為有效BD, 然後更新網路統計計數, 移動傳送BD的頭索引到下一位置, 並將新的傳送BD頭索引更新到ampeth.stat段中, 最後給AMP核發送一個IPI收包中斷, 通知AMP核可以從共享記憶體中接收資料了.
圖3 核間通訊虛擬網口傳送流程
AMP核間通訊虛擬網口的接收操作流程如圖4所示. 當AMP核接收到IPI收包中斷, 進入中斷處理函式後, 首先關閉核間IPI收包中斷, 然後喚醒收包執行緒進行收包. 為了避免大量的網路流量造成中斷風暴, 從而嚴重影響系統性能, 我們在進行收包前先關閉IPI收包中斷, 當有大量資料包進來後, 通過收包執行緒進行輪詢收包, 收完所有有效包後再開啟IPI收包中斷, 同時為了避免收包執行緒長時間收包占用處理器資源, 影響其他任務, 對輪詢收包的個數做了配額限制, 收包機制類似於Linux核心NAPI收包機制[21].
收包執行緒喚醒後, 首先檢查輪詢收包的個數是否超出了配額限制, 如果輪詢收包的個數超過64個, 則使能核間IPI中斷後等待下次喚醒. 如果收包個數未超過配額限制, 再檢查當前接收BD是否空閒, 如果空閒, 說明接收快取中的所有資料已全部接收, 使能核間IPI中斷後等待下次喚醒. 如果BD非空閒, 說明接收BD中有資料, 再檢查當前接收BD的len欄位是否有效, 如果無效則丟棄接收幀, 否則將BD的資料拷貝到接收記憶體空間, 並清除BD的valid和len欄位. 然後更新網路統計計數, 並移動接收BD的頭索引到下一位置, 將新的接收BD頭索引更新到ampeth.stat段中. 至此, 一個BD的收包處理完成.
圖4核間通訊虛擬網口接收流程
通過AMP核間通訊虛擬網口, AMP主核可以藉助完善的TCP/IP網路服務, 為從核提供更加豐富複雜的網路服務, 如網路檔案系統、FTP、ssh等; 另外傳統微機保護測控裝置取樣分散式硬體架構, 其板間通訊以網路通訊為主, 使用虛擬網口實現AMP核間通訊, 可以很好地相容現有微機保護測控裝置的嵌入式軟體架構和通訊機制.
4 工程應用
本方案應用於35kV及以下低壓保護測控裝置的研製, 裝置中的CPU板的核心器件包括四核處理器和FPGA. 處理器中的3個CPU核設定為SMP模式, 執行Linux作業系統; 1個CPU核設定為AMP模式, 執行實時作業系統. FPGA用於擴充套件電力專用網路（如MMS製造報文規範、GOOSE面向通用物件變電站事件網、SV取樣網等）和匯流排擴充套件（如開關量輸入輸出模組管理匯流排、快速報文匯流排、對時匯流排、人機介面模組通訊匯流排、列印通訊匯流排等）. 裝置保護動作響應時間小於10ms, 遙控傳輸延時小於1s, 遙信變化響應時間小於1s, 通過保護測控裝置的實時效能和功能測試[5-6]. 在網路報文攻擊和故障注入等異常測試中, 裝置無宕機或異常重啟, AMP從核上的保護、取樣等實時任務可靠執行.
裝置在正常負載情況下, AMP核間虛擬網口網路通訊耗時約50us左右, 其中Linux側收發包平均耗時約40us, RTOS側收發包平均耗時約10us, 而分散式多板卡方案中使用的百兆乙太網口網路通訊耗時約500us左右. AMP主從核通過AMP核間虛擬網口實現的網路檔案系統、遠端登入、埠轉發、網路對時等網路服務功能工作穩定, 效能符合裝置技術指標要求.
現有繼電保護裝置的AMP方案都是採用Zynq SOC晶片或異構處理器, 而不支援通用多核處理器.本方案的應用結果表明基於通用多核處理器的AMP方案是行之有效和穩定可靠的.
5 結語
本文提出一種基於通用多核處理器的AMP設計方案, 支援AMP核的生命週期管理和基於虛擬網口的核間通訊. 採用本方案研製的低壓保護測控裝置已批量發貨, 現場執行情況表明基於通用多核處理器的AMP方案, 能夠滿足電力二次裝置的實時效能要求. 總結來說, 本方案的優勢有如下幾點:
- 簡化軟硬體設計, 節約成本;
- 擴大處理器選型範圍; 相對於異構處理器, 通用多核處理器的選型範圍廣, 成熟度高;
- 基於虛擬網口的AMP核間通訊方案, 相容現有的分散式軟體架構和網路通訊機制.
後續計劃在電力二次裝置中應用本方案, 並適配到更多的多核處理器和實時作業系統中.
（本文發表於《計算機系統應用》第三十卷 第七期）
作者：wahaha02 出處：https://www.cnblogs.com/wahaha02 本文為博主原創文章，內容歡迎轉載或引用，但請註明出處。