百億億次級系統(tǒng)進程管理接口綜述

張 昆，張 偉，盧 凱，董 勇，戴屹欽

(國防科技大學(xué)計算機學(xué)院，湖南 長沙 410073)

1 引言

目前，高性能計算HPC(High Performance Computing)系統(tǒng)性能已經(jīng)進入百億億次時代，各國都向著實現(xiàn)百億億次計算性能目標(biāo)不斷行進，為提高經(jīng)濟競爭力、推進工業(yè)生產(chǎn)、改善人類社會生活創(chuàng)造更多切實效益。

進程管理是高性能計算的一個組成部分，在結(jié)點數(shù)量較少的計算系統(tǒng)中，進程管理的可擴展性對應(yīng)用程序運行沒有太大影響。但是，隨著系統(tǒng)規(guī)模擴大，傳統(tǒng)進程管理已經(jīng)不能滿足海量處理器核的需求，迫切需要一種可擴展的管理方式，且可以提供進程交換信息的機制。為了解決該問題，在進程管理中引入進程管理接口PMI(Process Management Interface)，用于在啟動階段部署進程的通信方法。引入后的進程管理包括3個部分[2]：并行編程庫(例如MPI庫)、PMI庫和進程管理器。進程管理器是一個邏輯上的中心進程，用于管理進程啟動與進程間信息傳遞。PMI庫通過API接口提供進程交換信息機制。并行編程庫可以通過PMI API來訪問進程管理器提供的啟動進程、初始化進程等各類功能。

IBM發(fā)布的報告[1]指出，實現(xiàn)百億億次級計算系統(tǒng)有5大瓶頸，其中一項就是通信瓶頸。為了突破這一瓶頸，在進程之間快速建立通信機制成為一項重要的研究課題。百億億次系統(tǒng)內(nèi)包含數(shù)萬結(jié)點與近千萬處理器核，以往PMI建立通信的方法無法滿足進程快速啟動的要求，大規(guī)模并行應(yīng)用的啟動時間過長，成為限制系統(tǒng)運行效率、降低系統(tǒng)易用性的一個重要因素。

為了解決百億億次級系統(tǒng)的啟動問題，進程管理接口發(fā)展出PMIx(Process Management Interface-Exascale)的版本，以實現(xiàn)在30 s內(nèi)啟動和連接大規(guī)模應(yīng)用程序進程的總體目標(biāo)[3]。PMIx定義了新的并行應(yīng)用程序啟動順序，并針對大規(guī)模應(yīng)用程序提出新的建立通信機制，力求縮短啟動時間，提高系統(tǒng)性能。

本文主要探討百億億次級計算性能目標(biāo)下，進程管理接口啟動大規(guī)模并行應(yīng)用程序的有效性，對比PMI-1、PMI-2和PMIx的工作機制與特點，分析PMIx對于作業(yè)快速啟動、系統(tǒng)高效運行的重要作用，以及在提升性能上做出的優(yōu)化，并討論未來的發(fā)展方向。

本文第2節(jié)介紹進程管理接口的發(fā)展過程和大規(guī)模并行應(yīng)用程序啟動過程，分析進程管理對于提高系統(tǒng)運行效率的重要意義；第3節(jié)分別介紹傳統(tǒng)的并行應(yīng)用程序啟動順序和PMIx模式下的并行應(yīng)用程序啟動順序，對比分析PMIx在改進啟動過程中所發(fā)揮的作用；第4節(jié)介紹為了提高系統(tǒng)性能，目前對PMIx所做的優(yōu)化研究；第5節(jié)從啟動并行應(yīng)用程序期間和運行時控制2個方面對未來PMIx的發(fā)展方向進行了說明。

2 背景

2.1 進程管理接口介紹

在現(xiàn)代高性能計算系統(tǒng)中，一個并行計算任務(wù)包含多個并行作業(yè)，每一個并行作業(yè)又包含一個或多個并行應(yīng)用程序，而每一個應(yīng)用程序則是一組二進制可執(zhí)行文件的實例化。在系統(tǒng)中啟動一個并行應(yīng)用程序主要包含以下幾步[4]：

(1)部署運行時環(huán)境。

該階段是在分配有作業(yè)的計算結(jié)點集上部署分布式的運行時環(huán)境RTE(Running Time Environment)。目前在大多數(shù)軟件堆棧中，該階段通常在分配的每一個計算結(jié)點上都創(chuàng)建一個RTE實例，用于后續(xù)生成和管理進程。

(2)啟動應(yīng)用程序進程。

在分配有作業(yè)的計算結(jié)點上，RTE實例生成相應(yīng)進程，并執(zhí)行進程啟動。

(3)獲取預(yù)定義環(huán)境信息。

在此階段，RTE將自身已知的作業(yè)級信息提供給應(yīng)用程序進程，如進程的rank信息、進程總數(shù)信息、共享同一計算結(jié)點的進程列表等。

(4)獲取動態(tài)環(huán)境信息。

在該階段，進程需要交換彼此特定于應(yīng)用程序的數(shù)據(jù)信息。這些是不包含在階段(3)中但進程必須知道的信息，例如通信尋址信息，通過定義的全局操作，進程獲得此類信息。

目前，大多數(shù)的高性能計算軟件堆棧都采用進程管理接口來完成階段(3)與階段(4)的工作。并行應(yīng)用程序進程通過PMI定義的API與RTE通信。PMI將信息組織成鍵值數(shù)據(jù)庫的形式，通過Put、Get和同步原語訪問數(shù)據(jù)庫。

在并行應(yīng)用程序啟動過程中，最耗時的階段為階段(4)。當(dāng)面對百億億次級系統(tǒng)時，進程數(shù)目龐大，所有進程彼此之間交換信息會花費大量時間，這對于實現(xiàn)快速啟動應(yīng)用程序的目標(biāo)十分不利。而PMIx則集中解決此階段問題，力求尋找獲取動態(tài)信息的新方法，盡可能將階段(4)中所需信息轉(zhuǎn)移到階段(3)中。通過減少進程交換信息操作的時間消耗，即使進程規(guī)模龐大，PMIx也可以達到快速啟動應(yīng)用程序的目標(biāo)，促進系統(tǒng)高效運行。

2.2 進程管理接口發(fā)展過程

隨著“異構(gòu)MPI”項目的研究，各國致力于開發(fā)可應(yīng)用于多臺不同類型計算機上的MPI，這就需要MPI程序能夠處理異構(gòu)的通信協(xié)議、安全性機制和調(diào)度程序等[5]，這激發(fā)工作人員研究一類定義在MPI中使用的通用API，用來執(zhí)行各類進程管理系統(tǒng)中的啟動、監(jiān)視和控制進程的功能[6]。

第1代PMI(PMI-1)被廣泛應(yīng)用在MPICH2[7]及其派生的MPI實現(xiàn)中[8]，其最初設(shè)計目標(biāo)是利用一個接口減少進程管理器與MPI實現(xiàn)之間的耦合。PMI-1主要包含2個部分，一部分旨在協(xié)助MPI初始化過程中的引導(dǎo)活動，另一部分旨在支持MPI中的動態(tài)進程管理功能。PMI-1設(shè)計人員使進程管理器只提供MPI進程交換信息的通用機制。該機制由一個鍵值存儲KVS(Key-Value Store)組成。經(jīng)過適當(dāng)?shù)耐讲僮?，一個進程放入KVS的內(nèi)容可以由另一個進程讀出。在PMI-1中，一個簡單的集體屏障功能保證了該類同步。一旦所有進程經(jīng)過屏障操作，則認為所有數(shù)據(jù)都已寫入；并且一旦經(jīng)過屏障操作釋放進程，進程就可以讀取所有數(shù)據(jù)。

但是，將PMI-1應(yīng)用于現(xiàn)代高性能計算系統(tǒng)上時，卻暴露出PMI-1的局限性。雖然在PMI-1中有一個鍵值數(shù)據(jù)庫用于存取，但進程管理器無法向數(shù)據(jù)庫中添加系統(tǒng)信息，導(dǎo)致MPI進程不能從進程管理器中查詢此類信息。另外，PMI-1不能保證線程安全，在給定的PMI連接上，同時只能執(zhí)行一個請求。并且，PMI-1中缺乏故障處理機制，無法在進程發(fā)生故障時重新生成進程。為了解決以上問題，開發(fā)人員設(shè)計出第2代進程管理接口(PMI-2)。

在PMI-2中，針對PMI-1的以下幾個方面進行了改進[2]：

(1)增加查詢功能。

PMI-2中加入了進程管理系統(tǒng)預(yù)定義的鍵。通過該類鍵，進程管理器將系統(tǒng)信息直接添加到鍵值庫中，MPI程序可以獲取與MPI進程相關(guān)的布局信息。

(2)擴大數(shù)據(jù)庫信息范圍。

PMI-1采用的是扁平化的數(shù)據(jù)庫，一個MPI進程不能限制它添加到數(shù)據(jù)庫中的鍵值的范圍。在此情況下，加入的信息都歸納為全局信息，進程無法單獨獲取僅與本地計算結(jié)點相關(guān)的子集信息。為了解決這個問題，PMI-2中引入了結(jié)點級別與全局級別的數(shù)據(jù)庫信息范圍，進程管理器可以更高效率地提取信息。

(3)增加線程安全。

PMI-1面臨多線程情況時，MPI實現(xiàn)調(diào)用PMI-1需使用適當(dāng)鎖機制保護。但是，PMI-1中的鎖機制是粗粒度的，當(dāng)PMI庫的一個查詢請求得到了進程管理器的響應(yīng)后，其他線程就無法在該套接字上通信。PMI-2則對PMI-1中線程安全的限制進行了修改，MPI實現(xiàn)不需要確保一次僅有一個線程調(diào)用PMI。

(4)改善容錯機制。

當(dāng)故障發(fā)生時，PMI-1沒有提供任何的進程重生機制進行處理。PMI-2提供了故障處理方法，利用重生的新進程取代同一進程組中的故障進程。

隨著超級計算機的發(fā)展，高性能計算系統(tǒng)面臨多層次的大規(guī)模并行處理，為了滿足百億億次級系統(tǒng)的要求，PMI社區(qū)開發(fā)出PMIx接口[3,9]。PMIx是專門設(shè)計用于支持百億億次級系統(tǒng)的進程管理接口，該接口以編程模型不可知的方式抽象出管理大規(guī)模應(yīng)用程序和監(jiān)視進程所必需的功能。

在PMI-2的基礎(chǔ)上，PMIx在功能上進行了進一步完善。相對于PMI-2中的數(shù)據(jù)庫信息范圍，PMIx將信息作用域增加到進程本地范圍、結(jié)點本地范圍、遠程范圍和全局范圍。另外，在PMI-1與PMI-2中，鍵值的數(shù)據(jù)類型僅定義為字符串，PMIx則擴展了數(shù)據(jù)表示，可對更多類型數(shù)據(jù)進行存儲。PMIx針對同步原語Fence和Get原語都加入了非阻塞版本，以降低操作延遲。同時，PMIx針對稀疏通信情況進行優(yōu)化，提供按需數(shù)據(jù)交換模式，縮短通信時間。更為關(guān)鍵的是，針對啟動大規(guī)模并行應(yīng)用程序，PMIx定義了新的啟動順序，力求降低傳統(tǒng)應(yīng)用程序啟動過程時間成本，加快程序啟動。

3 大規(guī)模并行應(yīng)用程序啟動過程優(yōu)化

隨著高性能計算處理問題規(guī)模不斷增大，傳統(tǒng)并行程序啟動過程顯露出弊端。大規(guī)模應(yīng)用程序的啟動時間成為一個不可忽視的問題，PMIx為了滿足百億億次級系統(tǒng)的要求，對傳統(tǒng)啟動順序進行調(diào)整，力求快速啟動應(yīng)用程序。表1對比分析了傳統(tǒng)應(yīng)用程序啟動順序與PMIx模式下的啟動順序。下面將對PMIx優(yōu)化并行應(yīng)用程序的啟動過程進行詳細介紹。

Table 1 Analysis of start sequence of parallel application表1 并行應(yīng)用程序啟動順序分析

3.1 傳統(tǒng)并行應(yīng)用程序啟動順序

傳統(tǒng)并行應(yīng)用程序的啟動順序大致分為以下6個不同的階段，如圖1[10]所示。

第1階段：用戶將作業(yè)組織成腳本或交互會話請求的形式，其中包含完成作業(yè)所需的資源類型與數(shù)量描述。而后，用戶將作業(yè)提交給工作負載管理器WLM(WorkLoad Manager)，等待作業(yè)執(zhí)行。

Figure 1 Traditional start sequence圖1 傳統(tǒng)啟動順序

第2階段： WLM根據(jù)作業(yè)優(yōu)先級、可支配資源數(shù)目和資源調(diào)度算法，將資源分配給作業(yè)，并將分配結(jié)果通知控制資源分配的資源管理器RM(Resource Manager)守護進程[11,12]。RM守護進程接收通知后，一方面在文件系統(tǒng)FS(File System)里獲取應(yīng)用進程二進制可執(zhí)行文件，實例化作業(yè)進程，圖1中“Spawn Procs”代表生成進程過程；另一方面從文件系統(tǒng)中加載實例化進程所需的動態(tài)依賴庫。

可是，在進程數(shù)目龐大的情況下，由于大量結(jié)點的多個進程會同時進行請求庫操作，極易引發(fā)“庫檢索風(fēng)暴”問題，導(dǎo)致文件系統(tǒng)壓力過大。

第3階段：進程實例化完成后，需要構(gòu)建進程之間的通信機制。每個進程都要提供交互所需的本地通信信息，例如進程rank和通信端點地址。當(dāng)進程獲取自身通信信息后，需要將該類信息發(fā)布到計算結(jié)點的本地代理上。

第4階段：結(jié)點的本地代理發(fā)現(xiàn)所有進程信息后，利用網(wǎng)絡(luò)上定義的全局操作[13]，完成結(jié)點與結(jié)點之間進程通信信息的全局交換過程，這一過程通常稱為名片交換或BCX(Business Card Exchange),圖1中“Global Xchg”代表該階段。這個階段是整個并行應(yīng)用程序啟動階段中最耗時的部分。大部分的研究都關(guān)注如何開發(fā)更高效方法，以減少此過程的時間開銷。

第5階段：結(jié)點完成信息全局交換后，需要根據(jù)所獲得的通信信息構(gòu)建通信通道。在這一階段，程序庫會基于本地代理上的信息進行基礎(chǔ)結(jié)構(gòu)的組裝，例如將通信通道映射到其他進程。這個階段的時間花費是從本地結(jié)點的代理服務(wù)器上檢索連接和其他所需信息所花的時間，以及每個進程配置其本地網(wǎng)絡(luò)接口卡NIC(Network Interface Cards)所需的時間。

第6階段：執(zhí)行全局的屏障操作，用來確認結(jié)點上的所有進程都已經(jīng)構(gòu)建完成通信結(jié)構(gòu)，可以進行通信。雖然這一過程并沒有對數(shù)據(jù)進行處理操作，但此階段是除全局交換外，另一個耗時最多的階段。在該階段，需要觀察計算結(jié)點上的每一個進程是否都成功完成通信設(shè)置，另外還需要確認本地高速網(wǎng)絡(luò)也處于接收信息的狀態(tài)。只有經(jīng)過該階段的屏障，才可以認為所有進程能夠進行交互。

隨著并行應(yīng)用程序進程數(shù)目的大幅度增加，傳統(tǒng)的啟動過程中第4階段進程交換信息和第6階段確認進程狀態(tài)過程都會花費過多時間。為了實現(xiàn)在短時間內(nèi)啟動大規(guī)模應(yīng)用程序，PMIx對傳統(tǒng)應(yīng)用程序啟動順序進行改進，力求消除全局交換的時間成本。

3.2 PMIx模式下并行應(yīng)用程序啟動順序

傳統(tǒng)啟動過程中耗時最大的部分是全局交換信息與執(zhí)行全局屏障階段，PMIx通過提供新的接口，調(diào)整并行應(yīng)用程序的啟動順序，力求去除以上2個階段。修改后的并行應(yīng)用程序理想啟動順序如下所示：

第0階段：該階段是針對系統(tǒng)資源進行的匯總過程，技術(shù)上來講并不是啟動過程的一部分，但資源目錄(包括交換機、網(wǎng)絡(luò)和結(jié)點拓撲等)對于應(yīng)用程序調(diào)度以及有效完成啟動過程至關(guān)重要。在該過程中，PMIx以動態(tài)方式處理資源，并對資源目錄實時更新，從而保證啟動過程的順利完成。

第1階段：用戶將作業(yè)組織成腳本或交互會話請求的形式，其中包含完成作業(yè)所需要的資源類型與數(shù)量描述。而后，用戶將作業(yè)提交給WLM，等待作業(yè)執(zhí)行。在該階段，WLM除了將請求記錄到適當(dāng)?shù)年犃兄?，還使用PMIx接口將請求傳遞到文件系統(tǒng)，以獲取所有用戶標(biāo)識的可執(zhí)行文件與支持庫。

第2階段：WLM根據(jù)作業(yè)優(yōu)先級、可支配資源數(shù)目和資源調(diào)度算法，將資源分配給作業(yè)。分配通常發(fā)生在當(dāng)前處理作業(yè)通知完成，啟動末尾操作之前。因此，在新作業(yè)調(diào)度開始之前，有一定的時間對資源分配進行預(yù)處理。

PMIx利用這段時間完成2個重要步驟。首先，它提供一個接口，WLM可以通過該接口通知FS分配情況，并將在初始階段確定的所需文件列表傳遞給FS。若此時存在可用緩存，文件系統(tǒng)將啟動進程用到的文件緩存到與分配結(jié)點相關(guān)內(nèi)存位置，通過定位所需文件，緩解文件系統(tǒng)檢索壓力。

其次，WLM利用另一個PMIx接口將分配情況和作業(yè)描述都傳遞給子系統(tǒng)，并接收一個“blob”，其中包含每個子系統(tǒng)對作業(yè)的支持信息(例如網(wǎng)絡(luò)系統(tǒng)對進程通信的支持信息)。標(biāo)記返回值來標(biāo)識哪些值直接提供給結(jié)點上的本地資源，以及哪些作為環(huán)境變量傳遞給應(yīng)用程序進程，環(huán)境變量在由特定進程初始化時會被資源識別。

第3階段：緩存所需文件并獲得網(wǎng)絡(luò)配置后，WLM將“blob”以及分配信息和資源目錄信息傳遞給已分配結(jié)點上的RM守護進程。在派生本地進程之前，每個RM守護進程都可以利用PMIx接口將配置信息傳遞給本地資源。RM守護進程向本地PMIx服務(wù)器注冊應(yīng)用程序和本地進程，從而為進程提供與應(yīng)用程序和本地環(huán)境有關(guān)的信息。完成操作后，RM守護程序?qū)⑴缮鷳?yīng)用程序進程。

第4階段：在進程初始化期間，每個進程調(diào)用PMIx_Init函數(shù)連接到本地PMIx服務(wù)器。PMIx服務(wù)器通知RM進程連接，并返回本地RM守護進程在注冊期間提供的所有信息。

至此，啟動序列完成，進程已經(jīng)獲取網(wǎng)絡(luò)系統(tǒng)的通信支持，可以自由通信。

但是，以上過程只是PMIx提出的一個理想啟動順序，目前還沒有在進程管理系統(tǒng)中完全實現(xiàn)。要完全消除傳統(tǒng)啟動過程中全局交換和全局屏障階段，需要對系統(tǒng)管理堆棧中的網(wǎng)絡(luò)庫與相應(yīng)的事件處理機制做進一步改進[14,15]。

目前，PMIx提供了2個可用于提高啟動性能的方法[3,9]。首先，在BCX操作中刪除本地RM守護進程提供給每個進程的數(shù)據(jù)，從而大大減少BCX操作中包含的數(shù)據(jù)量，減少全局交換信息的時間。另外，PMIx提出一種直接名片交換DBCX(Direct Business Card Exchange)的替代連接方法，該方法根據(jù)需要獲取所需進程的名片來代替BCX操作。每個進程發(fā)布的數(shù)據(jù)都緩存在本地PMIx服務(wù)器上，當(dāng)進程向特定進程請求名片時，進程首先檢查本地PMIx共享內(nèi)存段，以查看數(shù)據(jù)是否已可用。如果不可用，則將請求傳遞到本地服務(wù)器，服務(wù)器隨后請求主機RM守護進程從指定進程的PMIx服務(wù)器中檢索數(shù)據(jù)。然后，本地PMIx服務(wù)器將數(shù)據(jù)提供給請求的客戶端進程。雖然DBCX通過消除BCX操作允許更快的啟動速度，但檢索特定進程名片信息的效率較低。因而，DBCX更適合稀疏通信的環(huán)境，對于密集通信，還存在需要改進的地方。

4 進程管理接口性能優(yōu)化分析

PMIx啟動過程中耗時最長的部分是全局交換信息、建立通信機制的過程。為了快速啟動大規(guī)模并行應(yīng)用程序，目前對于PMIx的研究，大部分都集中在改進全局交換、建立大規(guī)模進程通信通道方面，研究者們針對PMIx啟動過程中的各個階段做出不同方面的優(yōu)化。本節(jié)從下列幾個方面介紹目前對于PMIx所進行的優(yōu)化研究：(1)優(yōu)化PMIx數(shù)據(jù)庫伸縮性；(2)優(yōu)化數(shù)據(jù)表示形式；(3)優(yōu)化PMIx運行時環(huán)境。

4.1 優(yōu)化PMIx數(shù)據(jù)庫伸縮性

在進程管理接口提供的交互方式里，資源管理器與應(yīng)用程序的信息交換是通過鍵值數(shù)據(jù)庫KVDb(Key-Value Database)來進行的。應(yīng)用程序進程通過PMI提供的Put原語將數(shù)據(jù)提交到KVDb中，利用特定的同步原語使數(shù)據(jù)庫接收所有進程Put的數(shù)據(jù)，而后進程調(diào)用Get原語從KVDb中獲取所需信息。

結(jié)點內(nèi)的KVDb訪問是影響PMI性能的主要原因之一，主要體現(xiàn)在Get原語的延遲問題。Chakraborty等人[16]對資源管理器SLURM中PMI-2實現(xiàn)的可伸縮性進行分析，將客戶進程與服務(wù)器的通信定義為影響通信效率的一個關(guān)鍵限制，并且他們也探討了利用共享內(nèi)存機制實現(xiàn)KVDb的優(yōu)勢，主要包含以下幾點：

(1)內(nèi)存消耗可伸縮：傳統(tǒng)方式在應(yīng)用程序的每一個進程上都復(fù)制一次KVDb的內(nèi)容，導(dǎo)致占用過多內(nèi)存。利用共享內(nèi)存機制，只需要在計算結(jié)點上存儲一次KVDb內(nèi)容，可減少存儲量。

(2)更優(yōu)的并行性：共享內(nèi)存允許客戶端在不涉及服務(wù)器的情況下獨立訪問KVDb。

(3)延遲更低：操作被允許可以按照CPU速度進行處理。

通過對PMI數(shù)據(jù)庫伸縮性進行優(yōu)化，從而降低Get原語的延遲，加快進程數(shù)據(jù)訪問，提升資源管理器性能。與PMI-1和PMI-2相比，PMIx提供了更優(yōu)的數(shù)據(jù)訪問能力，一方面對作業(yè)級信息進行擴展，資源管理器可以直接獲得作業(yè)環(huán)境的信息；另一方面，PMIx允許按需獲取信息，在PMIx_Get中可以從KVDb中獲得指定進程的信息。

PMI中原有的鎖機制是POSIX線程[17]中的Read/Write locks(RW-locks)鎖機制，該類鎖的可伸縮性十分有限。為了進一步減少PMIx_Get操作延遲，Polyakov等人[18]基于文獻[19]中的靜態(tài)算法在PMIx的2.1版本中提出2N-lock鎖機制。通過引入信號鎖解決靜態(tài)算法中寫入器易餓死的問題，信號鎖不易被讀取器獲取，但可以被寫入器獲取。寫入器需要首先獲得所有信號鎖，然后獲取讀取鎖進行寫入操作。

另外，Polyakov等人[18]發(fā)現(xiàn)PMIx_Get中的線程轉(zhuǎn)換也是影響性能的另一個限制因素。由于在PMIx 2.1版本的參考實現(xiàn)里，共享內(nèi)存組件無法訪問PMIx實現(xiàn)的全局狀態(tài)，作者提出了新的線程安全轉(zhuǎn)換方案：在PMIx_Get獲取所需數(shù)據(jù)后，再進行線程shift操作，從而避免讀寫數(shù)據(jù)過程中的線程shift操作帶來的延遲。對比原有實現(xiàn)，新提出的PMIx主機通信的鎖定與線程安全方案，在168 PPN(Processors Per Node)情況下，最高可減少PMIx_Get操作66倍的延遲。

4.2 優(yōu)化數(shù)據(jù)表示形式

這一部分的優(yōu)化是針對PMIx啟動過程中全局交換信息階段的數(shù)據(jù)量大小進行的，通過精簡交換信息的數(shù)據(jù)量，去除不必要的重復(fù)信息，從而緩解數(shù)據(jù)交換的壓力，加速信息交換過程。并且，更精簡的數(shù)據(jù)表示形式也可以減少存儲空間占用，這對于大規(guī)模并行程序來說效果更為明顯。

表2針對PMIx啟動過程中涉及到的在數(shù)據(jù)表示形式方面所做的不同優(yōu)化方式的效果進行了總結(jié)，簡要介紹了各類方法的優(yōu)化對象和優(yōu)化方式，對比優(yōu)化前與優(yōu)化后數(shù)據(jù)表示形式的字節(jié)大小，分析所提出方法的優(yōu)化效果，本節(jié)后續(xù)將對各類優(yōu)化方法的具體內(nèi)容進行詳細介紹。

Table 2 Summary of data representation optimization mechanisms表2 數(shù)據(jù)表示形式優(yōu)化機制總結(jié)

4.2.1 優(yōu)化通信地址信息

Polyakov等人[20]使用基于UCX(Unified Communication X)通信的PMIx高性能軟件棧對數(shù)據(jù)布局進行優(yōu)化。UCX是一個高級通信庫，其地址信息中包含進程建立連接過程中用到的所有信息，如通信地址、地址長度、通道特征等。Polyakov等人[20]通過去除地址表示中的通道特征和地址長度等通用信息，將通信實體地址信息大小從51 B降低到21 B，優(yōu)化了60%。

4.2.2 優(yōu)化進程交換數(shù)據(jù)表示

在PMIx中，進程交換全局信息時，通過調(diào)用運行時環(huán)境的Fence函數(shù)確保KVDb的全局信息同步，這是整個并行應(yīng)用程序啟動過程中最耗時的部分[21]。Fence函數(shù)通過交換每個運行結(jié)點上的數(shù)據(jù)塊來保證信息同步，數(shù)據(jù)塊由頭部信息與進程組件信息組成，進程組件信息按照進程rank排序，每一個進程組件由進程標(biāo)識符與進程鍵值對組成。為了減少交換的數(shù)據(jù)量信息，Polyakov等人[20]對數(shù)據(jù)塊中各部分進行了如下優(yōu)化：

(1)優(yōu)化進程標(biāo)識符表示。

一直以來，進程標(biāo)識符是由進程namespace與rank組成。namespace字段由運行時環(huán)境所分配，在不同的運行時環(huán)境中，該字段的長度是不同的。在Open RTE(Run Time Environment)環(huán)境中，namespace字段大小為10 B，而在SLURM中，該字段至少為21 B。Polyakov等人對PMIx_Fence進行分析發(fā)現(xiàn)，參與同步操作的進程必須是同一namespace中的，這就表示參與同步操作的進程可組成一個固定序列，只需用一個大小為4 B的序列號標(biāo)識進程即可，減少了進程標(biāo)識符的內(nèi)存占用。

(2)優(yōu)化鍵值對表示。

在2.1版本及以前的PMIx參考實現(xiàn)里，一個鍵值對中key的表示形式為(namespace,rank,key-name)，并且PMIx_Get原語可以識別請求key所在的進程的rank值，這導(dǎo)致相同的key可能在數(shù)據(jù)塊中重復(fù)出現(xiàn)。本文通過建立關(guān)于key的索引表，并只用key在表中的整數(shù)索引(大小為4 B)標(biāo)識key的位置，對鍵值對表示進行優(yōu)化。對于每個結(jié)點上N個進程(PPN為N)的情況，若key字段大小為s個字節(jié)，另外需要4個字節(jié)來表示key的長度，則一個key共需占用N*(s+4)個字節(jié)；引入索引表后，上述情況只需占用(s+4)+4*N個字節(jié)，對比減少占用s*(N-1)-4個字節(jié)，對于高性能計算軟件堆棧，優(yōu)化效果明顯。

(3)優(yōu)化數(shù)值編碼方式。

在2.1版本及以前的PMIx參考實現(xiàn)里的數(shù)值表示中，為了防止數(shù)據(jù)溢出，通常采用一個相比數(shù)值實際大小要大很多的數(shù)據(jù)類型來表示數(shù)據(jù)。例如對于鍵值對中的value字段，不論鍵值真實大小，統(tǒng)一采用uint64數(shù)據(jù)類型定義鍵值，在內(nèi)存中占用[21;256] B。這種方法在一定程度上造成了空間浪費，當(dāng)進程數(shù)目較多時，浪費更為明顯。本文采用Little-Endian Base 128(LEB128)[22]編碼方式，僅把所需要的字節(jié)打包到緩沖區(qū)中，避免了數(shù)據(jù)類型造成的多余空間浪費，優(yōu)化了數(shù)據(jù)占用空間。

4.3 優(yōu)化PMIx運行性時環(huán)境

針對分布式計算運行時環(huán)境的問題，目前已經(jīng)有了一系列的研究，每一類方法都集中解決一類特定問題。MPICH提供了多種運行時環(huán)境[23]，例如Hydra[24]、MPD(MultiPrupose Daemon)[25]、Gforker等。Hydra可以很好地擴展單個結(jié)點上的大量進程，與混合編程模型可有效交互；雖然Hydra可以檢測和報告MPI進程失敗，但無法處理故障進程。MPD通過一個環(huán)形拓撲連接結(jié)點，然而MPD彈性差，如果2個結(jié)點故障會將所有結(jié)點分成2個單獨的結(jié)點組，從而阻止故障結(jié)點的通信；另外，MPD也不具備可伸縮性。

OPEN RTE[26]是OPEN MPI[27]的運行時環(huán)境，用于啟動、監(jiān)視和殺死并行作業(yè)，通過各種拓撲連接守護進程，但是通信并不可靠。PRETE運行時環(huán)境是PMIx規(guī)范的參考實現(xiàn)，技術(shù)上屬于OPEN RTE的一個分支，繼承了OPEN RTE中啟動和監(jiān)視MPI作業(yè)的大部分功能，能夠部署各種各樣的并行應(yīng)用程序和工具。

針對不同的運行時環(huán)境，在PMIx中可進行不同的優(yōu)化措施，目前已有的針對運行時環(huán)境優(yōu)化的研究有：

Polyakov等人[20]針對SLURM[28]運行時環(huán)境中PMIx_Fence操作進行優(yōu)化，將PMIx_Fence與MPI Allgatherv[29]操作對比分析，采用調(diào)整后的Bruck級聯(lián)算法作為Fence操作。作者在108個結(jié)點上進行實驗，以SLURM 18.08作為運行時環(huán)境，利用提出的集體算法與原有的樹形Fence操作、環(huán)形Fence操作進行實驗對比。結(jié)果表明，在108個結(jié)點上，當(dāng)消息的規(guī)模從20字節(jié)擴展到214字節(jié)時，相比樹形算法和環(huán)形算法，集體算法有效降低了Fence操作延遲。

為了在系統(tǒng)上有效運行計算任務(wù)，處理系統(tǒng)故障具有重要意義[30]。Zhong等人[31]針對PMI-x的參考運行時環(huán)境(PRRTE)中的故障處理進行研究，實現(xiàn)一種高效運行時故障檢測，每個參與者只在可恢復(fù)的環(huán)拓撲之后觀察單個對等點，利用多個重疊的拓撲進行優(yōu)化檢測與傳播，最小化故障檢測開銷并保證框架的可伸縮性，加快進程故障處理。作者提出的方法權(quán)衡了系統(tǒng)開銷、檢測效率和檢測風(fēng)險之間的復(fù)雜關(guān)系，既可以承受結(jié)點與故障檢測的高頻特性，同時具有較低程度的拓撲結(jié)構(gòu)，為在大型系統(tǒng)上有效進行故障管理提供了新的思路。

4.4 進程管理接口優(yōu)化機制效果對比

4.1～4.3節(jié)中介紹了目前PMIx在數(shù)據(jù)庫伸縮性、數(shù)據(jù)表示形式、運行時環(huán)境3方面所做的優(yōu)化研究，表3對這3類優(yōu)化機制效果進行了綜合分析，探討每一類優(yōu)化機制的側(cè)重點方向，通過對比為未來優(yōu)化方向提供研究思路。

Table 3 Comparison and analysis of different PMIx optimization mechanisms表3 不同PMIx優(yōu)化機制效果對比分析

5 結(jié)束語

為了早日實現(xiàn)百億億次計算目標(biāo)，PMIx社區(qū)與各國研究人員一直致力于改進PMIx，以實現(xiàn)在更短時間內(nèi)啟動大規(guī)模進程的啟動目標(biāo)。本節(jié)主要從PMIx對于并行應(yīng)用程序啟動期間和運行時控制2個方面對PMIx未來的發(fā)展方向進行介紹。

5.1 并行應(yīng)用程序啟動期間

并行應(yīng)用程序啟動期間，在所有計算結(jié)點上實例化可執(zhí)行文件及其依賴庫的時間是影響啟動過程的重要因素，當(dāng)大規(guī)模進程同時請求加載一個依賴庫時，容易引發(fā)“庫檢索風(fēng)暴”問題。

目前，PMIx正在定義新的API，優(yōu)化可執(zhí)行文件的實例化。為了緩解文件系統(tǒng)的檢索壓力，未來PMIx正致力于通過預(yù)先定義的接口對作業(yè)腳本進行分析，提前獲得所執(zhí)行作業(yè)的動態(tài)依賴庫信息，調(diào)用腳本級的指令提前發(fā)現(xiàn)所需的依賴文件，預(yù)定位到存儲管理器中，并利用二進制文件執(zhí)行動態(tài)庫的加載。

在進程建立通信階段，探索新的進程通信方式，當(dāng)前發(fā)布的PMIx 3.0版本提供了為進程分配靜態(tài)端口的函數(shù)。在未來的資源管理器中，可以利用此類接口取消進程動態(tài)分配通信端口的過程，從而消除全局交換信息階段帶來的時間成本問題。

5.2 運行時控制

目前PMIx對于運行時控制的優(yōu)化主要集中于對存儲數(shù)據(jù)方面的控制能力，例如對于并行應(yīng)用程序數(shù)據(jù)重定位或存儲策略的能力，目前這方面的研究還處于起步階段，在未來還有很大改進空間。當(dāng)前，PMIx正致力于發(fā)展以下幾個方面：

(1)增強并行應(yīng)用程序進程向資源管理器匯報數(shù)據(jù)存儲情況，并將當(dāng)前系統(tǒng)可用的資源實時更新通知到資源管理器。

(2)加強并行應(yīng)用程序的進程向資源管理器查詢當(dāng)前數(shù)據(jù)的存儲情況，快速獲取進程所需數(shù)據(jù)的位置以及當(dāng)前資源管理器存儲方式等信息。

(3)進一步加強PMIx對于事件的處理機制，利用觸發(fā)器及時激發(fā)事件進行事務(wù)處理；提高故障處理能力，合理應(yīng)對系統(tǒng)運行過程中可能出現(xiàn)的各類問題，加強對于數(shù)據(jù)庫更新的管控能力。