基于“嵩山”超級(jí)計(jì)算機(jī)的UCX 庫分析與優(yōu)化

劉 康，萬 偉，劉 波，李俊宏，李 柱

（鄭州大學(xué) 計(jì)算機(jī)與人工智能學(xué)院，鄭州 450001）

0 概述

“嵩山”超級(jí)計(jì)算機(jī)部署于國家超級(jí)計(jì)算鄭州中心，是我國國產(chǎn)自研的新一代超高性能計(jì)算平臺(tái)，它采用32 核CPU+國產(chǎn)加速器的異構(gòu)計(jì)算架構(gòu)、InfiniBand（直譯為“無限帶寬”技術(shù)，縮寫為IB）［1-2］超高速網(wǎng)絡(luò)以及高性能分布式并行存儲(chǔ)系統(tǒng)，理論峰值算力可達(dá)100 PFlops，整機(jī)實(shí)測(cè)性能達(dá)到65 PFlops。InfiniBand 是一個(gè)用于高性能計(jì)算平臺(tái)的計(jì)算機(jī)網(wǎng)絡(luò)通信標(biāo)準(zhǔn)，具有極高的吞吐量和極低的延遲，用于計(jì)算機(jī)與計(jì)算機(jī)之間的數(shù)據(jù)互連，也用作服務(wù)器與存儲(chǔ)的互連以及存儲(chǔ)系統(tǒng)之間的互連。InfiniBand搭載的Mellanox ConnectX-6 網(wǎng)卡提供了最高200 Gb/s帶寬的數(shù)據(jù)傳輸性能。

“嵩山”計(jì)算平臺(tái)所搭載的主要通信框架為UCX（Unified Communication X）［3-4］。UCX 作為底層InfiniBand 網(wǎng)絡(luò)和上層并行編程模型的通信中間件，定義了一組統(tǒng)一的標(biāo)準(zhǔn)化通信編程接口，以滿足主流的并行編程模型，如MPI（Message Passing Interface）［5］、UPC（Unified Parallel C）［6］、PGAS（Partitioned Global Address Space）［7］等的需求，同時(shí)又可以在各種高性能平臺(tái)上實(shí)現(xiàn)，以便在互聯(lián)網(wǎng)絡(luò)上更好地滿足高性能、可移植、可伸縮等并行應(yīng)用的開發(fā)需求［8-10］。

但是，由于RDMA（Remote Direct Memory Access）系統(tǒng)具有復(fù)雜性，因此存在很多未知的問題［11-12］，UCX 作為“嵩山”RDMA 系統(tǒng)中的通信框架，在“嵩山”特色互聯(lián)網(wǎng)絡(luò)架構(gòu)上還有一定的優(yōu)化空間。在存在復(fù)雜通信環(huán)境的集合通信中，通信有時(shí)會(huì)成為瓶頸而拖累了整體計(jì)算速度。UCX 的通信性能直接影響了上層并行編程模型的數(shù)據(jù)傳輸與計(jì)算性能。因此，在“嵩山”超級(jí)計(jì)算平臺(tái)上對(duì)UCX 進(jìn)行研究與優(yōu)化具有重要的工程意義。

本文基于“嵩山”超級(jí)計(jì)算平臺(tái)，以MPI 為例，使用osu_benchmark 測(cè)試工具［13］在不同的傳輸下進(jìn)行多種集合通信測(cè)試，獲得各種情形下的延遲與帶寬數(shù)據(jù)，以發(fā)現(xiàn)節(jié)點(diǎn)設(shè)備存在的瓶頸。同時(shí)，對(duì)UCX的代碼進(jìn)行優(yōu)化，以解決節(jié)點(diǎn)內(nèi)通信占用網(wǎng)卡資源的問題。在此基礎(chǔ)上，實(shí)現(xiàn)UCX 在“嵩山”超級(jí)計(jì)算平臺(tái)上的最優(yōu)傳輸選擇，以提升平臺(tái)的集合通信能力以及整體的計(jì)算性能。

1 “嵩山”超級(jí)計(jì)算機(jī)互聯(lián)網(wǎng)絡(luò)

1.1 InfiniBand 互聯(lián)網(wǎng)絡(luò)

InfiniBand 是一種高速互聯(lián)網(wǎng)絡(luò)，用于連接大型集群和超級(jí)計(jì)算機(jī)，它是目前應(yīng)用最廣泛的高速互連網(wǎng)絡(luò)之一，2016 年在Top500 互連網(wǎng)絡(luò)中就已經(jīng)達(dá)到37.5%的份額［14］。InfiniBand 網(wǎng)絡(luò)為通信提供了雙邊（發(fā)送-接收）和單邊（RDMA）語義。InfiniBand上的通信使用隊(duì)列對(duì)（QP）模型，其中，發(fā)送和接收隊(duì)列分別用于發(fā)送和接收消息，工作請(qǐng)求被提交到這些隊(duì)列中，硬件可以在隊(duì)列中讀取工作請(qǐng)求以執(zhí)行通信。此外，將隊(duì)列與每個(gè)QP 相關(guān)聯(lián)，用于通知通信完成。在通過InfiniBand 進(jìn)行通信時(shí)，需要注意注冊(cè)硬件訪問的所有內(nèi)存區(qū)域。為了減少內(nèi)存注冊(cè)的開銷，短消息（Short）可以內(nèi)聯(lián)到工作請(qǐng)求中，而較大的消息可以利用零拷貝（ZCopy）協(xié)議。這種策略意味著工作請(qǐng)求只獲取內(nèi)存緩沖區(qū)的描述信息，然后直接從緩沖區(qū)讀取數(shù)據(jù)，而不需要CPU 的參與。

當(dāng)前InfiniBand 結(jié)構(gòu)實(shí)現(xiàn)了各種傳輸機(jī)制［15-16］，最常見的是RC（面向連接的可靠連接）和UD（無連接的不可靠數(shù)據(jù)報(bào)），后者只實(shí)現(xiàn)了雙邊通信語義。此外，UD 一次只能傳輸一個(gè)MTU 的數(shù)據(jù)（通常是4 KB），而RC 通常能提供比UD 更高的帶寬和更低的延遲，代價(jià)是RC 對(duì)資源有很高的要求：要完全連接N個(gè)進(jìn)程；要求每個(gè)進(jìn)程有O（N2）個(gè)連接和O（N）個(gè)隊(duì)列對(duì)。而UD 是無連接的，因此，每個(gè)進(jìn)程只需要一個(gè)UD 隊(duì)列對(duì)。為了減少RC 的內(nèi)存消耗，InfiniBand 規(guī)范引入了共享接受隊(duì)列以及擴(kuò)展的RC傳輸。Mellanox 后續(xù)又推出了動(dòng)態(tài)連接（DC）傳輸服務(wù)［17］，該服務(wù)動(dòng)態(tài)地創(chuàng)建和銷毀連接，將內(nèi)存消耗限制在接近UD 的級(jí)別，同時(shí)提供與RC 類似的內(nèi)存語義。然而，DC 的可擴(kuò)展性設(shè)計(jì)是以性能為代價(jià)的，主要是因?yàn)榇嬖谶B接事務(wù)的開銷［18］。

InfiniBand 的用戶 空間接口是Verbs API［19］，它是一個(gè)帶有OFED 堆棧的用戶級(jí)別的庫，位于內(nèi)核級(jí)Verbs API 之上。內(nèi)核API 與特定供應(yīng)商的InfiniBand 驅(qū)動(dòng)程序和驅(qū)動(dòng)程序庫協(xié)作，以實(shí)現(xiàn)InfiniBand 硬件訪問。InfiniBand 軟件棧示意圖如圖1 所示。

圖1 InfiniBand 軟件棧和UCXFig.1 InfiniBand software stack and UCX

1.2 Socket Direct 技術(shù)

隨著數(shù)據(jù)量的指數(shù)級(jí)增長(zhǎng)，使用者對(duì)服務(wù)器和計(jì)算資源提出了更高的性能要求，以便對(duì)海量數(shù)據(jù)進(jìn)行實(shí)時(shí)分析。“嵩山”超級(jí)計(jì)算平臺(tái)采用非均勻內(nèi)存訪問（NUMA）架構(gòu)［20］，每個(gè)處理器擁有4 個(gè)CPU Die，在每個(gè)Die 內(nèi)集成了8 個(gè)物理核心，共計(jì)32 個(gè)物理核心。

在一般情況下，數(shù)據(jù)主要依靠GMI 總線來進(jìn)行跨Die 傳輸，如圖2（a）所示，此時(shí)Die3/Die4 中的數(shù)據(jù)如果要傳輸至網(wǎng)卡，則網(wǎng)絡(luò)流量需要使用GMI 總線經(jīng)過Die0/Die1 然后再流入網(wǎng)卡。而“嵩山”平臺(tái)的網(wǎng)絡(luò)架構(gòu)支持Socket Direct 技術(shù)，該技術(shù)可以使節(jié)點(diǎn)中的每個(gè)Die（NUMA node）都可以通過其專用的PCIe 接口直接連接到網(wǎng)絡(luò)，使得網(wǎng)絡(luò)流量無須遍歷內(nèi)部總線（GMI）和其他Die，如圖2（b）所示。Socket Direct 不僅降低了CPU 的利用率、增加了網(wǎng)絡(luò)吞吐量，還顯著降低了開銷與延遲，從而提高了服務(wù)器的性能。

圖2 跨Die 傳輸?shù)膶?duì)比Fig.2 Comparison of cross-Die transmission

1.3 UCX 設(shè)計(jì)

隨著DPU 的普及以及各類DSA 芯片的廣泛使用［21］，如何在這之上抽象出統(tǒng)一的內(nèi)存訪問語義和統(tǒng)一的通信方式成為一個(gè)值得研究的問題，因此，UCX 應(yīng)運(yùn)而生。UCX 可以在通信方面實(shí)現(xiàn)低級(jí)別的軟件開銷，并且提供接近原生級(jí)別的性能。UCX旨在提供一個(gè)統(tǒng)一的抽象通信接口，能夠適配任何通信設(shè)備，并支持各種應(yīng)用的需求，從而滿足當(dāng)前高性能、可移植且穩(wěn)定可靠的并行應(yīng)用開發(fā)需求，同時(shí)還能通過持續(xù)的迭代更新來適應(yīng)未來的高速互聯(lián)網(wǎng)絡(luò)。

從圖1 可以看出UCX 軟件堆棧是如何放置在InfiniBand 之上的，UCX 由下層UCT 和上層UCP 這2 層組成。下文將介紹UCX 框架，討論UCP 和UCT這2 個(gè)層之間的主要區(qū)別以及UCX 內(nèi)部最重要的語義。

1.3.1 UCX 框架

UCX 利用高速網(wǎng)絡(luò)進(jìn)行節(jié)點(diǎn)間通信，并利用共享內(nèi)存機(jī)制進(jìn)行有效的節(jié)點(diǎn)內(nèi)通信。UCX 總體采用分層結(jié)構(gòu)公開一組抽象通信原語，這些原語充分利用了可用的硬件資源和負(fù)載，其中包括RDMA［22-23］（InfiniBand 和RoCE）、TCP、共享內(nèi)存和網(wǎng)絡(luò)原子操作。圖3 顯示了UCX 的軟件棧結(jié)構(gòu)。

圖3 UCX 軟件棧結(jié)構(gòu)Fig.3 UCX software stack structure

UCX 通過提供高級(jí)API 促進(jìn)快速開發(fā)，屏蔽低層細(xì)節(jié)，同時(shí)保持高性能和可伸縮性，其框架主要由3 個(gè)組件組成，即UCS（UC-Services）、UCT（UCTransports）和UCP（UC-Protocols）。每一 個(gè)組件都導(dǎo)出一個(gè)公共API，可以作為一個(gè)獨(dú)立的庫使用。底層的UCT 適配各種通信設(shè)備，上層的UCP 則是在UCT 不同設(shè)備的基礎(chǔ)上封裝更抽象的通信接口，以方便使用。

UCT 是傳輸層，它抽象了各種硬件架構(gòu)之間的差異，并提供了一個(gè)支持通信協(xié)議實(shí)現(xiàn)的低級(jí)API，從單機(jī)的共享內(nèi)存到常用的TCP Socket 以及“嵩山”超算底層的InfiniBand 協(xié)議，都有很好的支持。該層的主要目標(biāo)是提供對(duì)硬件網(wǎng)絡(luò)功能的直接有效訪問，為此，UCT 依賴供應(yīng)商提供的低級(jí)驅(qū)動(dòng)程序，如InfiniBand Verbs、Cray 的uGNI 等。此外，該層還提供用于通信上下文管理（基于線程和應(yīng)用程序級(jí)別）以及分配和管理的構(gòu)造。在通信API 方面，UCT 定義了立即（short）、緩沖復(fù)制、發(fā)送（BCopy）和零拷貝（ZCopy）等通信操作的接口。

UCP 是協(xié)議層，通過使用UCT 層公開的較低級(jí)別功能來實(shí)現(xiàn)上層高級(jí)編程模型（如MPI、UPC、PGAS）所使用的較高級(jí)別協(xié)議。UCP 提供的功能是能夠?yàn)橥ㄐ胚x擇不同的傳輸、消息分段、多軌通信以及初始化和完成庫。目前，API 具有的接口類別包括初始化、遠(yuǎn)程內(nèi)存訪問（RMA）通信、原子內(nèi)存操作（AMO）、活動(dòng)消息（Active Message）、標(biāo)簽匹配（Tag-Matching）和集合（Collectives）。

1.3.2 UCX 語義

UCX 提供的最主要語義包括通信上下文、通信原語、通信實(shí)體和連接建立。這4 種語義詳細(xì)敘述如下：

1）通信上下文。UCP 和UCT 的最主要區(qū)別在于通信上下文。UCT 被設(shè)計(jì)成一個(gè)位于單個(gè)通信設(shè)備和傳輸層之上的通信層，而UCP 可以讓用戶操作不同的設(shè)備和傳輸層。因此，UCT 在設(shè)備（如InfiniBand、共享內(nèi)存SM）上定義了一個(gè)內(nèi)存域，用來分配和注冊(cè)進(jìn)行通信的內(nèi)存以及特定設(shè)備（如InfiniBand 上的UD 和RC）上的特定傳輸接口。內(nèi)存域和接口都有一組它們自己的屬性，這些屬性來自于硬件功能。內(nèi)存域?qū)傩园▋?nèi)存分配限制和內(nèi)存訪問的憑據(jù)，接口屬性包括傳輸機(jī)制的通信和連接能力以及協(xié)議切換的閾值。UCP 將這些多個(gè)UCT內(nèi)存域和接口封裝在單個(gè)通信上下文中，并根據(jù)硬件屬性和性能指標(biāo)選擇適合通信操作的接口。

3）通信實(shí)體。Worker 是UCX、UCP 和UCT 的核心通信實(shí)體。Worker 的主要特征是有自己的進(jìn)度引擎（progress engine），進(jìn)度引擎會(huì)在所有打開的接口上強(qiáng)制執(zhí)行當(dāng)前的進(jìn)度。在Worker 要啟用與另一個(gè)進(jìn)程的通信時(shí)，每個(gè)進(jìn)程都會(huì)創(chuàng)建一個(gè)端點(diǎn)（endpoint），并將其連接到遠(yuǎn)程進(jìn)程的endpoint。UCT endpoint 與特定接口（如UD、RC）綁定，即每個(gè)使用的接口對(duì)應(yīng)一個(gè)UCT endpoint，而UCP endpoint擁有多個(gè)UCT endpoint。因此，在UCP 中，endpoint始終連接著2 個(gè)Worker。在內(nèi)部，UCP 負(fù)責(zé)從可用于執(zhí)行通信操作的接口/UCT endpoint 中選擇最佳的接口/UCT endpoint。

4）連接建立。當(dāng)UCP 的Worker 創(chuàng)建endpoint時(shí)，UCP 層為每種類型的操作選擇一個(gè)或多個(gè)接口，并且在每個(gè)接口上創(chuàng)建并對(duì)應(yīng)一個(gè)UCT endpoint，所有的這些UCT endpoint 都與父UCP endpoint 相關(guān)聯(lián)。如果一個(gè)接口對(duì)應(yīng)無連接的傳輸，那么它可以立即連接到遠(yuǎn)程接口，這也就是UCP 中發(fā)生的情況，即UCT endpoint 通過無連接傳輸立即建立連接。但是，如果接口對(duì)應(yīng)P2P 的傳輸，UCP 將創(chuàng)建一個(gè)stub endpoint。Wireup UCT endpoint 始終是無連接的，通過立即發(fā)送Wireup 請(qǐng)求然后通過P2P 傳輸以實(shí)現(xiàn)所有UCT endpoint 的連接。當(dāng)父UCP endpoint 的所有UCT endpoint 都已連接時(shí)，stub endpoint 即被銷 毀。

2 UCX 在“嵩山”中的優(yōu)化

2.1 參數(shù)調(diào)優(yōu)

UCX 可以適配多種設(shè)備、系統(tǒng)、架構(gòu)等，因而具有繁雜的參數(shù)設(shè)置，調(diào)整各項(xiàng)參數(shù)可以使UCX 更加適配“嵩山”平臺(tái)。

“嵩山”平臺(tái)的高速網(wǎng)絡(luò)使用Socket Direct技術(shù)劃分CPU 為4 個(gè)NUMA nodes 并分別連接至4 塊網(wǎng)卡設(shè)備，實(shí)現(xiàn)各個(gè)Die 與網(wǎng)卡的直連。在UCX 中設(shè)置UCX_MAX_RNDV_LANES 為4，為Rendezvous 協(xié) 議開啟4 端口的多軌傳輸，使用多塊網(wǎng)卡同時(shí)進(jìn)行傳輸，從而提升數(shù)據(jù)的傳輸效率。

“嵩山”平臺(tái)CPU 使用的NUMA 架構(gòu)，在PCIe總線傳輸中更適合采用寬松排序（relaxed order）的事務(wù)排序方法，即允許PCIe 交換開關(guān)，將軟件確認(rèn)過的事務(wù)重排在其他事務(wù)之前發(fā)送，這樣既提升了PCIe 總線效率，又能保證程序如期執(zhí)行。本文使用UCX_IB_PCI_RELAXED_ORDERING=on 在UCX 中開啟寬松排序，使得所有使用UCX 通信庫的程序采用寬松排序，從而獲得更高的性能。

2.2 網(wǎng)卡占用優(yōu)化

在使用UCX 進(jìn)行節(jié)點(diǎn)內(nèi)部通信時(shí)，進(jìn)程間通信不僅會(huì)使用共享內(nèi)存?zhèn)鬏?，還會(huì)調(diào)用網(wǎng)卡設(shè)備共同完成數(shù)據(jù)傳輸，這是由于ITIGIN［4］為UCX 添加了實(shí)現(xiàn)，即進(jìn)行進(jìn)程間通信時(shí)rc 會(huì)輔助共享通信，從而共同完成通信。但是在“嵩山”平臺(tái)上，實(shí)測(cè)IB 網(wǎng)卡對(duì)多進(jìn)程的通信支持相較于共享內(nèi)存并不友好，多進(jìn)程會(huì)平分網(wǎng)卡帶寬，導(dǎo)致整體性能下降。而在進(jìn)行大規(guī)模節(jié)點(diǎn)運(yùn)算時(shí)，網(wǎng)卡是節(jié)點(diǎn)間通信的主力設(shè)備，應(yīng)該盡可能地保證網(wǎng)卡用于跨節(jié)點(diǎn)傳輸。因此，需要對(duì)UCX 的傳輸邏輯進(jìn)行修改，使其在進(jìn)行節(jié)點(diǎn)間通信時(shí)不使用網(wǎng)卡。

以MPI 為例，在其進(jìn)行通信時(shí)，UCX 會(huì)調(diào)用遠(yuǎn)程內(nèi)存訪問（RMA）［24］和活動(dòng)消息（AM）等操作來實(shí)現(xiàn)快速的節(jié)點(diǎn)間通信。在涉及進(jìn)程間通信時(shí)，UCX同樣也會(huì)選擇網(wǎng)卡來調(diào)用這些操作進(jìn)行傳輸。

在“嵩山”超級(jí)計(jì)算平臺(tái)中，MPI 節(jié)點(diǎn)內(nèi)通信使用的設(shè)備有memory 和mlx5。memory 會(huì)調(diào)用am、am_bw 和 rma_bw 操 作；mlx5 網(wǎng)卡會(huì)調(diào)用am_bw 和rma_bw 操作。因此，mlx5 網(wǎng)卡在節(jié)點(diǎn)內(nèi)通信時(shí)所調(diào)用的操作完全可以被memory 所取代。程序調(diào)用am_bw 和rma_bw 操作之 前，UCT 會(huì)執(zhí)行ucp_wireup_add_bw_lanes 函數(shù)，選出合適的傳輸，以此建立支持相應(yīng)功能的endpoint。對(duì)此函數(shù)進(jìn)行分析可以發(fā)現(xiàn)，函數(shù)調(diào)用ucp_wireup_select_transport，根據(jù)bitmap 選出支持am_bw 或rma_bw 的傳輸，隨后函數(shù)將傳輸放入ep 的配置文件中，等待endpoint 的創(chuàng)建，這些操作都發(fā)生在連接的準(zhǔn)備階段。

在實(shí)驗(yàn)確定的最佳色譜條件下，選取1#果酒樣品，分別加入10，50，100 mg/L標(biāo)準(zhǔn)混合溶液，平行進(jìn)行6次實(shí)驗(yàn)，實(shí)驗(yàn)結(jié)果見表3。回收率為81.6%～102.8%，相對(duì)平均偏差不大于4.4%，說明方法精密度高，準(zhǔn)確度好。

本文在ucp_wireup_add_bw_lanes 函數(shù)中添加判斷。在函數(shù)循環(huán)搜尋可用傳輸并將其添加到設(shè)備的dev_bitmap 后，讀取出Worker 的上下文信息，判斷此時(shí)的設(shè)備是否為共享內(nèi)存?zhèn)鬏敚喝绻枪蚕韮?nèi)存?zhèn)鬏?，則break 跳出循環(huán)，不再搜索額外的傳輸；如果不是共享內(nèi)存?zhèn)鬏?，則正常循環(huán)，搜尋可用傳輸。修改后的程序流程如圖4 所示，可以這樣做的原因是搜索過程中的設(shè)備次序memory 排在mlx5 網(wǎng)卡之前，當(dāng)選擇出共享內(nèi)存?zhèn)鬏敃r(shí)，函數(shù)退出，便不會(huì)檢索到mlx5 網(wǎng)卡，從而在進(jìn)行節(jié)點(diǎn)內(nèi)的進(jìn)程間通信時(shí)只使用共享內(nèi)存通信而不是網(wǎng)卡傳輸。

圖4 優(yōu)化后的程序流程Fig.4 Optimized program procedure

使用osu_benchmark 以4 MB 包長(zhǎng)測(cè)得單節(jié)點(diǎn)內(nèi)2～32 進(jìn)程的alltoall 集合通信延遲數(shù)據(jù)，如圖5 所示，其中，before 是優(yōu)化前同時(shí)使用網(wǎng)卡rc 傳輸和共享內(nèi)存?zhèn)鬏數(shù)耐ㄐ艛?shù)據(jù)，after 是僅使用共享內(nèi)存?zhèn)鬏數(shù)耐ㄐ艛?shù)據(jù)。從圖5 可以看出，在節(jié)點(diǎn)內(nèi)通信時(shí)，隨著PPN（Processes Per Node）的增加，2 種傳輸方式的延遲差距愈加明顯，優(yōu)化后的通信延遲相較于優(yōu)化前最多降低了70%。

圖5 節(jié)點(diǎn)內(nèi)alltoall 測(cè)試結(jié)果Fig.5 Intra-node alltoall test results

測(cè)試不同PPN 下的點(diǎn)對(duì)點(diǎn)通信帶寬數(shù)據(jù)，如圖6所示。從中可以明顯看出，在PPN 大于8 時(shí)，僅使用共享內(nèi)存?zhèn)鬏數(shù)耐ㄐ判阅軆?yōu)于使用IB 網(wǎng)卡的通信性能，此外，如果節(jié)點(diǎn)內(nèi)的進(jìn)程間通信使用了網(wǎng)卡傳輸，在絕大多數(shù)情況下，網(wǎng)卡通信還會(huì)對(duì)本來的進(jìn)程間通信造成負(fù)面影響，降低整體的通信帶寬性能。

圖6 節(jié)點(diǎn)內(nèi)點(diǎn)對(duì)點(diǎn)帶寬測(cè)試結(jié)果Fig.6 Intra-node p2p bandwidth test results

2.3 共享內(nèi)存通信選擇優(yōu)化

“嵩山”平臺(tái)的MPI 庫中存在不同的節(jié)點(diǎn)內(nèi)通信機(jī)制，圖7 主要展示了其中的2 種。傳統(tǒng)的雙副本拷貝的共享內(nèi)存實(shí)現(xiàn)，其傳輸數(shù)據(jù)涉及一個(gè)共享的緩沖區(qū)空間，由本地進(jìn)程來交換消息，如圖7（a）所示。但是，這種方式僅適用于小消息，對(duì)于較大的消息，雙副本拷貝會(huì)給CPU 帶來額外的負(fù)擔(dān)，導(dǎo)致緩存污染和帶寬的浪費(fèi)。圖7（b）展示了支持內(nèi)核輔助的共享內(nèi)存?zhèn)鬏攲?shí)現(xiàn)［25］，傳輸實(shí)現(xiàn)依靠?jī)?nèi)核的援助，內(nèi)核模塊可以為節(jié)點(diǎn)內(nèi)通信提供單拷貝機(jī)制，在傳輸較大消息時(shí)會(huì)大幅提升傳輸效率。

圖7 2 種共享內(nèi)存通信機(jī)制Fig.7 Two shared memory communication mechanisms

對(duì)于第2 種通信方式，“嵩山”平臺(tái)的MPI 庫支持CMA 和KNEM［26］這2 種內(nèi)核模塊。CMA 引入了2 個(gè)系統(tǒng)調(diào)用，分別是process_vm_readv 和process_vm_writev，它們根據(jù)進(jìn)程的PID 和遠(yuǎn)程虛擬地址直接讀寫另一個(gè)進(jìn)程的內(nèi)存［27］。對(duì)于使用KNEM 內(nèi)核的通信，發(fā)送進(jìn)程在KNEM 驅(qū)動(dòng)中聲明一個(gè)發(fā)送緩沖區(qū)（不管是否連續(xù)），并將相應(yīng)的標(biāo)識(shí)符cookie傳遞給接收進(jìn)程，接收進(jìn)程接收到cookie 并請(qǐng)求KNEM 驅(qū)動(dòng)從cookie 緩沖區(qū)復(fù)制到它的本地緩沖區(qū)（連續(xù)或非連續(xù)）［26］。

本文使用osu_benchmark 分別指定CMA 和KNEM 傳輸，測(cè)得2 種共享內(nèi)存通信的帶寬與延遲如表1 所示。在“嵩山”超算平臺(tái)下對(duì)輸出的UCX 日志進(jìn)行分析發(fā)現(xiàn)，節(jié)點(diǎn)在進(jìn)行共享內(nèi)存?zhèn)鬏敃r(shí)，無論何種情況都只會(huì)選擇CMA 進(jìn)行通信，并不會(huì)選擇帶寬更高、延遲更低的KNEM。

表1 CMA 與KNEM 的性能參數(shù)Table 1 Performance parameters of the CMA and KNEM

進(jìn)程間在進(jìn)行共享內(nèi)存通信時(shí)，通過rma_bw 操作來進(jìn)行高速的遠(yuǎn)程內(nèi)存訪問。在建立連接前，UCT 會(huì)根據(jù)UCX 提供的一套公式來計(jì)算傳輸評(píng)分，選出rma_bw 中評(píng)分最高的傳輸，添加到連接通道（lanes）中。

本文對(duì)rma_bw 操作傳輸選擇的評(píng)分機(jī)制進(jìn)行分析。在UCT 中，計(jì)算評(píng)分時(shí)以256 KB 的消息大小為基準(zhǔn)，調(diào)用rma_bw 操作的傳輸?shù)脑u(píng)分為時(shí)間開銷的倒數(shù)，如式（1）所示：

設(shè)mcost為內(nèi)存域注冊(cè)開銷，注冊(cè)開銷近似為一個(gè)線性函數(shù)，如式（2）所示：

其中：omd為固定開銷；ggrowth為增長(zhǎng)系數(shù)；ssize為數(shù)據(jù)大小（256 KB）。設(shè)bl和br分別為本地和遠(yuǎn)程的帶寬大小，因此，總開銷為256 KB 消息的傳輸時(shí)延、內(nèi)存注冊(cè)開銷mcost與傳輸接口間延遲llr的累加，如下：

對(duì)于節(jié)點(diǎn)中的每個(gè)進(jìn)程，其帶寬b在UCX 中的計(jì)算方式如式（4）所示：

其中：bdedicated為專用帶寬；bshared為共享帶寬。

對(duì)平臺(tái)的UCX 源代碼進(jìn)行分析，可以發(fā)現(xiàn)：在UCX 1.9.0 的帶寬設(shè)置下，CMA 擁有11 145.00 MB的dedicated 帶 寬，而KNEM 是13 862 MB 的shared帶寬。根據(jù)srma的計(jì)算公式，在PPN 不為1 時(shí)，UCX在計(jì)算KNEM 和CMA 的rma_bw 評(píng)分時(shí)帶寬會(huì)存在巨大差異，從而導(dǎo)致永遠(yuǎn)不會(huì)選擇KNEM 傳輸。這是因?yàn)樵缙贙NEM 對(duì)多進(jìn)程支持不如CMA，單進(jìn)程時(shí)KNEM 會(huì)有更高的帶寬，但是存在多進(jìn)程通信時(shí)，KNEM 性能將不如CMA，因而將KNEM 帶寬值設(shè)置為shared。但是，“嵩山”超級(jí)計(jì)算平臺(tái)所具有的優(yōu)化KNEM 對(duì)多進(jìn)程的支持極好，同時(shí)支持高性能單拷貝消息傳輸。因此，本文將KNEM 的帶寬從shared 改為dedicated，使KNEM 獲得了更合理的評(píng)分，從而在進(jìn)行集合通信時(shí)共享內(nèi)存方面的傳輸會(huì)更多地選擇帶寬更高、延遲更低的KNEM。

在大部分通信中，KNEM 和CMA 兩者差異較小，但是在涉及節(jié)點(diǎn)內(nèi)進(jìn)程間gather 通信時(shí)，KNEM內(nèi)核相對(duì)CMA 內(nèi)核有較為明顯的性能提升，并且隨著PPN 的增加提升效果愈加明顯，如圖8 所示。

圖8 節(jié)點(diǎn)內(nèi)gather 測(cè)試結(jié)果Fig.8 Intra-node gather test results

3 數(shù)據(jù)測(cè)試與驗(yàn)證

3.1 實(shí)驗(yàn)環(huán)境

在“嵩山”超級(jí)計(jì)算機(jī)的固化節(jié)點(diǎn)上進(jìn)行實(shí)驗(yàn)，單個(gè)節(jié)點(diǎn)配置為32 核2.0 GHz CPU，網(wǎng)卡采用Mellanox ConnectX-6，以HDR 模式（200 Gb/s）工作。操作系統(tǒng)為CentOS 7.6，內(nèi)核版本為3.10.0-957.el7.x86_64。

在本次測(cè)試中，使用的MPI 版本為Open MPI v4.0.4rc3，它在平臺(tái)的共享內(nèi)存通信時(shí)支持KNEM和CMA 內(nèi)核。使用的HPCX 版本為2.7.4，UCX 版本為UCX 1.9。對(duì)于點(diǎn)到點(diǎn)和集合通信測(cè)試，使用osu_benchmark v5.5 來測(cè)試并記錄通信性能數(shù)據(jù)。在性能測(cè)試對(duì)比數(shù)據(jù)中，before 的通信底層是目前在用的由ITIGIN 優(yōu)化后的UCX 正式版本，after 采用本文優(yōu)化后的UCX 庫。

3.2 節(jié)點(diǎn)內(nèi)集合通信測(cè)試

首先測(cè)試優(yōu)化后的UCX 庫在單節(jié)點(diǎn)內(nèi)的通信表現(xiàn)。圖9～圖11 展示了單節(jié)點(diǎn)內(nèi)不同PPN 下的4 MB 包長(zhǎng)的MPI 集合通信測(cè)試數(shù)據(jù)，橫坐標(biāo)為使用核心數(shù)（總進(jìn)程數(shù)），縱坐標(biāo)為平均通信延遲，每個(gè)核心綁定一個(gè)進(jìn)程進(jìn)行通信。從中可以看出，使用優(yōu)化后UCX 的MPI 集合通信能力有了明顯提升，alltoall 的通信性能提升尤為明顯，延遲最多降至優(yōu)化前的30%（圖9），gather 的通信延遲最多約降至優(yōu)化前的55%（圖10），allreduce 的通信延遲最多約降至優(yōu)化前的69%（圖11）。

圖9 優(yōu)化前后節(jié)點(diǎn)內(nèi)alltoall 測(cè)試結(jié)果Fig.9 Intra-node alltoall test results before and after optimization

圖10 優(yōu)化前后節(jié)點(diǎn)內(nèi)gather 測(cè)試結(jié)果Fig.10 Intra-node gather test results before and after optimization

圖11 優(yōu)化前后節(jié)點(diǎn)內(nèi)allreduce 測(cè)試結(jié)果Fig.11 Intra-node allreduce test results before and after optimization

3.3 節(jié)點(diǎn)間集合通信測(cè)試

對(duì)于節(jié)點(diǎn)間的集合通信，本文對(duì)2 個(gè)規(guī)模（32 節(jié)點(diǎn)和100 節(jié)點(diǎn)）進(jìn)行測(cè)試。對(duì)于32 節(jié)點(diǎn)的規(guī)模，選取分屬lka 2 個(gè)交換機(jī)的32 個(gè)節(jié)點(diǎn)，每個(gè)交換機(jī)16 個(gè)節(jié)點(diǎn)，測(cè)試消息包長(zhǎng)為1 MB。經(jīng)過測(cè)試發(fā)現(xiàn)，在節(jié)點(diǎn)間集合通信時(shí)，其他集合通信測(cè)試效果與優(yōu)化前一致，allgather通信產(chǎn)生了較為明顯的差異，如圖12 所示。

圖12 32 節(jié)點(diǎn)allgather 測(cè)試結(jié)果Fig.12 32 nodes allgather test results

本文在8 箱的節(jié)點(diǎn)中隨機(jī)選擇100 個(gè)節(jié)點(diǎn)，進(jìn)行100 個(gè)節(jié)點(diǎn)間的集合通信測(cè)試，獲得節(jié)點(diǎn)間的2～18 PPN 下1 MB 包長(zhǎng)的集合通信延遲數(shù)據(jù)。從圖13 可以看出，優(yōu)化后的UCX 在allgather 集合通信中取得了極為明顯的優(yōu)化效果，延遲最多可降至原來的20%，并且隨著進(jìn)程的增多差距逐漸變大。其他的集合通信測(cè)試優(yōu)化前后數(shù)據(jù)基本保持一致。

圖13 100 節(jié)點(diǎn)allgather 測(cè)試結(jié)果Fig.13 100 nodes allgather test results

4 結(jié)束語

“嵩山”超級(jí)計(jì)算平臺(tái)支持多種并行編程模型，對(duì)高速互聯(lián)網(wǎng)絡(luò)進(jìn)行優(yōu)化有助于提升平臺(tái)的整體通信性能，為平臺(tái)的并行編程模型提供良好的底層通信支持。本文對(duì)“嵩山”超級(jí)計(jì)算平臺(tái)上的節(jié)點(diǎn)進(jìn)行測(cè)試，獲得了節(jié)點(diǎn)間與節(jié)點(diǎn)內(nèi)的通信性能數(shù)據(jù)，并且發(fā)現(xiàn)IB 網(wǎng)卡在節(jié)點(diǎn)內(nèi)多PPN 通信中存在的局限性。然后，對(duì)平臺(tái)的主要通信框架UCX 進(jìn)行分析與優(yōu)化，解決了節(jié)點(diǎn)內(nèi)進(jìn)程間通信占用網(wǎng)卡的問題，同時(shí)改善了UCX 對(duì)共享內(nèi)存?zhèn)鬏數(shù)倪x擇機(jī)制。優(yōu)化后的UCX 對(duì)大PPN 下的節(jié)點(diǎn)間allgather 集合通信以及節(jié)點(diǎn)內(nèi)的進(jìn)程間集合通信性能提升效果明顯。

由于RDMA 具有復(fù)雜性，很多因素都可能影響RDMA 系統(tǒng)的整體通信性能。下一步將找出其他制約節(jié)點(diǎn)間通信速度的因素，對(duì)算法進(jìn)行改進(jìn)，使得節(jié)點(diǎn)間的其他集合通信能力得到加強(qiáng)。此外，UCX 根據(jù)PPN 來預(yù)測(cè)帶寬，依此帶寬來選擇傳輸，這種帶寬計(jì)算方法還不夠準(zhǔn)確，未來將對(duì)此進(jìn)行改進(jìn)，從而改善UCX 的傳輸選擇評(píng)分機(jī)制。