日本黄色一级经典视频|伊人久久精品视频|亚洲黄色色周成人视频九九九|av免费网址黄色小短片|黄色Av无码亚洲成年人|亚洲1区2区3区无码|真人黄片免费观看|无码一级小说欧美日免费三级|日韩中文字幕91在线看|精品久久久无码中文字幕边打电话

當前位置:首頁 > 嵌入式 > 嵌入式軟件
[導讀]針對MPI集群通信的特點,通過分析當前網絡的通信結構和MPI的點到點通信模式,提出了一種基于數據鏈路層的集群通信機制,用以減少協議開銷和內存拷貝次數,從而提高集群節(jié)點間的通信性能,并且通過實驗驗證了該機制的可行性。

在集群計算系統中,隨著系統規(guī)模的增大,通信效率是影響整個系統獲得高性能的關鍵因素之一。而隨著局域網傳輸性能的快速提高,Myrinet、Gigabit Ethernet和Infiniband等千兆位網絡設備已被廣泛使用,當前影響集群節(jié)點間通信性能的瓶頸已經從通信硬件的傳送開銷轉移到了通信處理軟件的開銷上,所以采用優(yōu)化的通信協議是降低通信成本、提高結點間通信的有效手段。

在當前的集群通信應用中,普遍采用兩類通信結構,即核心級通信和用戶級通信。但由于它們設計的初衷并非是針對集群通信,所以并不適合當前集群環(huán)境的特點。為此,本文通過分析這兩類通信結構的特點,提出了以核心級通信為基礎,旁路內核中IP層及以上協議層,實現數據鏈路層直接與MPI通道接口層通信的新機制,并通過實驗驗證,為傳統集群的升級改造提供一種新的無連接、無差錯控制,開銷小、延時低的通信機制。

1 基于數據鏈路層的集群通信結構的提出

目前各種通信協議普遍采用兩種通信結構,即核心級通信和用戶級通信[1]。

1.1 核心級通信

在核心級通信中,操作系統內核控制著所有消息傳遞中的發(fā)送與接收處理,并且負責它們的緩沖管理和通信協議的實現,設備驅動程序也是通過內核來完成所有的硬件支持與協議軟件處理的任務,如圖1所示。在通信過程中,系統要經過多次內核態(tài)與用戶態(tài)之間的數據拷貝才能夠實現數據的傳送。有數據表明[2],一般奔騰處理器的內存拷貝速率平均為70 Mb/s,但是由于操作系統在交換頁面時的 I/O 數據傳送都是阻塞操作,若出現缺頁中斷,其時延將會更大,所以頻繁的內存拷貝操作的開銷將是影響整體性能的瓶頸所在。因此,對于通信效率要求較高的集群計算系統,核心級通信是不適合的。


1.2 用戶級通信

在用戶級通信中,操作系統內核將網絡接口控制器NIC(Network Interface Controller)的寄存器和存儲器映射到用戶地址空間,允許用戶進程旁路操作系統內核從直接訪問NIC,直接將數據從用戶空間發(fā)送到網絡中進行傳輸。通信事件處理的觸發(fā)采用查詢方式而不是中斷方式,由于旁路操作系統內核,使得整個通信過程省掉了執(zhí)行系統調用、用戶態(tài)與核心態(tài)之間的數據拷貝及用戶與內核的上下文切換等軟件上的開銷,進而減少對主機CPU資源的占用,縮短通信操作的關鍵路徑,實現通信與計算的重疊。如圖2所示[3]。

但是,采用用戶級通信協議時,通信過程中的所有操作均在用戶空間中進行,當用戶程序出錯或有惡意用戶進行破壞時,系統就很容易被破壞。這是因為系統數據結構中不僅包含本進程(或并行任務)及其相關信息,同時也包含與本進程無關的其他進程(或并行任務)的相關信息。若某一用戶(并行任務)出錯或失誤,都將會影響到其他用戶(并行任務)的執(zhí)行,因而很難保證系統的安全性和可靠性,也無法保證并行任務間的相互獨立性。

1.3 基于數據鏈路層通信

為了既能保證系統安全、可靠以及并行任務間相互獨立,同時又能降低通信成本,本文提出了一種以核心級通信為基礎的基于數據鏈路層的通信結構,即在操作系統內核(以Linux內核為例)中旁路IP層、INET Socke層和BSD Socket層,使得數據鏈路層直接與應用程序的通道接口層通信。如圖3所示。

圖3中陰影部分表示通信關鍵路徑上數據鏈路層。在該通信結構下,系統在通信的關鍵路徑上將通過內存映射和內存拷貝兩種技術實現通信。在發(fā)送消息時,系統通過內存映射技術將消息映射到內核中的緩沖區(qū),注冊協議標識,并調用數據鏈路層函數對其進行封包發(fā)送;在接收消息時,系統通過數據鏈路層的MAC地址進行尋址、接收消息,并通過內存拷貝直接將消息傳送到用戶空間中的應用程序,實現點到點通信。

與用戶級通信結構相比,基于數據鏈路層的通信結構在通信關鍵路徑上只增加了一次內存拷貝的開銷。同時,由于保留了數據鏈路層的通信,進而為系統的安全性、可靠性和并行任務間的獨立性提供了保障。此外,該通信結構可以屏蔽系統的硬件信息,使得在應用程序中不再出現與系統通信硬件有關的操作。

與核心級通信結構相比,該通信結構在通信關鍵路徑上減少了協議處理開銷、數據拷貝次數和冗余的差錯校驗,進而提高了系統的通信效率。

2 MPI的通信

MPI(Message Passing Interface)是為基于消息傳遞的并行程序設計提供一個高效、可擴展、統一的編程環(huán)境,是目前主流的并行編程模式,也是分布式并行系統的主要編程環(huán)境。在集群環(huán)境中MPI并行程序設計中使用的通信模式有阻塞通信、非阻塞通信和組通信,其中阻塞通信和非阻塞通信屬于點對點通信,而點對點通信也正是MPI其他通信的基礎。

在阻塞通信中,當發(fā)送調用函數MPI_Send后即被阻塞,這時,系統會將發(fā)送緩沖區(qū)中的數據拷貝到系統緩沖區(qū),由系統負責發(fā)送消息,而發(fā)送者的操作只在拷貝操作完成時結束并返回,不必等待發(fā)送完成。但是,如果系統緩沖區(qū)不足或消息過長,導致拷貝失敗,則發(fā)送者將被阻塞,直到消息發(fā)送完成為止;同樣,當接收者在調用函數MPI_Recv后會被阻塞,直至收到匹配的消息為止[3]。

非阻塞通信主要是通過實現計算與通信的重疊,進而提高整個程序的執(zhí)行效率。對于非阻塞通信,不必等到通信操作完全結束后才可返回,而是由特定的通信硬件完成通信操作。在通信硬件執(zhí)行通信操作的同時,處理機可以同時進行計算操作,這樣便實現了通信與計算的重疊。發(fā)送者調用函數MPI_Isend或接收者調用數MPI_Irecv后,處理機便可執(zhí)行其他計算任務。在發(fā)送(接收)操作開始時,發(fā)送者(接收者)使用請求句柄(request handler),MPI通過檢查請求來決定發(fā)送(接收)操作是否完成,發(fā)送者(接收者)通過調用MPI_Test來確定發(fā)送(接收)操作是否完成。在發(fā)送或接收操作期間,發(fā)送者不能更改發(fā)送緩沖區(qū)中的內容,接收者也不能使用接收緩沖區(qū)中的內容。若發(fā)送者(接收者)調用函數MPI_Wait,則發(fā)送者(接收者)會被阻塞,直到發(fā)送(接收)操作完成才能返回[4]。

由此可知,MPI點到點通信在發(fā)送緩沖區(qū)、接收緩沖區(qū)和內核中的系統緩沖區(qū)之間進行傳遞,并由內核發(fā)送或接收系統緩沖區(qū)中的消息,本文提出的新通信機制就是圍繞著系統緩沖區(qū)展開的。

3 基于數據鏈路層的MPI通信機制的設計與實現

若要實現本文所提出的基于數據鏈路層的集群通信機制,則需要開發(fā)一個中間件DLMC(Data_link Layer MPI Communication)用于提供雙方進行通信的底層交換協議、數據包校驗、用戶空間與內核空間的數據交換和重傳機制等。這里需要注意的問題有:

(1)編譯方式

對于Linux內核編譯分為直接編譯進內核和通過模塊編譯加載進內核。本系統采用模塊加載的方式進行編譯,其理由是由于系統是在傳統Linux網絡下進行的修改,只有MPI計算才會用到此中間件,而對于計算之外的部分仍然要依靠傳統的TCP/IP。例如計算前期的準備工作,雖然模塊加載比直接編譯的效率低,但它可以隨意動態(tài)加載和卸載,這樣不僅靈活,而且有利于開發(fā)、調試等工作。

(2)用戶空間和內核空間之間的數據交換

基于數據鏈路層的通信進程是在內核空間運行的,而MPI進程是在用戶空間進行的,所以需要在用戶空間和內核空間進行通信。通過利用Linux內核機制,在用戶空間緩存頁面以及物理頁面之間建立映射關系,將物理內存映射到進程的地址空間,從而達到直接內存訪問的目的。

在Linux中,對于高端物理內存(896 MB之后),并沒有與內核地址空間建立對應的關系(即虛擬地址=物理地址+PAGE_OFFSET),所以不能使用諸如get_free_pages()函數進行內存分配,而必須使用alloc_pages()來得到struct *page結構,然后將其映射到內核地址空間,但此時映射后的地址并非和物理地址相差PAGE_OFFSET[5]。為實現內存映射技術,其具體使用方法是:使用alloc_pages()在高端存儲器區(qū)得到struct *page結構,然后調用kmap(struct *page)在內核地址空間PAGE_OFFSET+896M之后的地址空間中建立永久映射。DLMC首先讓內核得到用戶空間中發(fā)送緩沖區(qū)的頁信息,再將其映射到內核地址空間,并且返回內核虛擬地址,以供DLMC直接將發(fā)送緩沖區(qū)中的數據傳遞到數據鏈路層進行發(fā)送,這樣就完成了用戶地址空間到內核地址空間的映射。

(3)校驗與重傳機制

由于數據鏈路層的傳輸是一種不可靠的網絡傳輸方式,涉及到對傳輸數據進行數據校驗重傳等工作??紤]到局域網或者機對機傳輸的穩(wěn)定性和可靠性,系統校驗方式使用簡單的數據校驗和,重傳機制使用選擇重傳ARQ方案。當出現差錯必須重傳時,不必重復傳送已經正確到達接收端的數據幀,而只重傳出錯的數據幀或計時器超時的數據幀,以避免網絡資源的浪費。

(4)中斷機制

由于本系統改變了TCP/IP的傳輸機制,所以需要對發(fā)出的數據包進行協議標識。系統在初始化階段,調用內核的dev_add_pack()函數向內核注冊了標識為Ox080A的網絡數據處理函數。在發(fā)送數據包時,系統先通過kmap()函數將MPI的發(fā)送緩沖區(qū)sendbuff映射到內核映射緩沖區(qū)sysbuff,以軟中斷的方式通知系統,申請分配一個新的SKB來存儲sysbuff里的數據包,調用dev_queue_xmit函數,使數據包向下層傳遞,并清空sysbuff,釋放SKB。在接收端需要向內核注冊相應的硬件中斷處理函數,在接收到數據后喚醒上層的處理函數,并在netif_receive_skb函數(net/core/dev.c)中屏蔽將SKB包向上層傳遞的語句,改為將SKB里的數據以MPI數據包格式通過copy_to_user函數拷貝到MPI的接收緩沖區(qū)recvbuff中,完成數據的接收,其傳輸過程如圖4所示。


4 實驗結果與分析

4.1 實驗結果和方法

本實驗環(huán)境是一個4節(jié)點的Beowulf集群系統,每個節(jié)點包含一個PIV處理器和2 GB內存,操作系統采用Redhat Linux Enterprise 5,并行集群軟件為OPEN MPI 1.3。由于條件所限,加之實驗規(guī)模較小,本實驗采用MPI自帶的函數MPI_Wtime()來采集MPI計算的開始時間和結束時間,取二者的時間差作為程序的運行時間并對其進行比較和分析。

由于本實驗的目的是要測試基于數據鏈路層的通信機制的可行性,而該通信機制是在TCP/IP協議基礎之上構建的,所以本實驗對象將以單機系統、基于TCP/IP的MPI集群和基于DLMC的MPI集群作為參照平臺進行測試。在實驗用例設計上,考慮到兩種MPI集群的通信機制中的傳輸路徑不同,所以采用如下兩種測試方案:

(1)計算圓周率,主要測試系統的數學函數浮點計算性能,以點對點短消息傳輸為主;

(2)計算求解三對角方程組,主要測試通信和計算的平衡,以點對點長消息傳輸為主。

4.2 性能分析

(1)計算圓周率,如表1所示。

測試結果表明,在精度值設為10-8,精確值比較大時,基于TCP/IP的集群(4個進程)的運行時間是19.540 237 s,單機系統(單進程)運行時間是84.798 166 s,并行運算效果明顯。在精度值設為10-4,精確值比較小時,基于TCP/IP的集群(4個進程)的運行時間是0.026 346 s,單機系統(單進程)運行時間是0.013 742 s,這是由于并行運算過程中,參與運算的機器需要通過網絡傳遞消息,若計算量規(guī)模不大,則在網絡傳輸上花費的時間會比較多,所以反不如單機的運行速度快。從基于DLMC的集群與基于TCP/IP的集群運行結果對比看,在精度值較大時,前者略微快于后者,而在精度值較小時,后者略快于前者,這主要是因為基于TCP/IP的MPI集群在發(fā)送和接收的整個過程中,需要2次數據拷貝,即發(fā)送緩沖區(qū)到內核的拷貝和內核到接收緩沖區(qū)的拷貝,同時還有經過各協議層的開銷。而基于DLMC的MPI集群在整個的傳輸過程中,通過使用內存映射,只需要1次數據拷貝,同時旁路IP層及以上各協議層,在這種以短消息傳輸為主的測試中使得DLMC集群不能發(fā)揮其在網絡傳輸上的優(yōu)勢,所以在精度值較大時,二者相差無幾;在精度值較小時,反而基于TCP/IP的集群更快一些,這是因為內存映射和內核操作所引入的開銷大于1次內存拷貝開銷而造成性能的下降。

(2)計算求解三對角方程組,如表2所示。

由測試結果表明,在傳輸消息較小時,基于DLMC的MPI集群花費的時間略微小于基于TCP/IP的MPI集群,這說明此時基于內存映射和內核調用等操作的開銷要高于兩次數據拷貝的開銷,造成網絡延遲略高。但隨著傳輸消息規(guī)模的增大,特別是消息大小超過1 MB時,基于內存映射和數據鏈路層協議的DLMC相對于具有2次內存拷貝的多協議機制的網絡延時要小得多,這樣使得系統的整體運行時間明顯低于傳統的TCP/IP集群。

由上分析可知,基于Linux數據鏈路層的集群通信機制是可行的。在該機制下構建的MPI集群系統完成了無IP條件下的數據傳輸,并且支持多用戶調用,在傳輸過程中減少了協議開銷、和內存拷貝次數,相比于TCP/IP傳輸有一定提高。但是基于數據鏈路層協議的特點,該機制只能在局域網范圍內運行,所以集群節(jié)點數量或規(guī)模會受到一定的限制,只能適合中小集群系統的應用。由于實驗條件的有限,對集群通信系統未能充分驗證,希望在今后的研發(fā)工作中能夠進一步加強。

本站聲明: 本文章由作者或相關機構授權發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內容真實性等。需要轉載請聯系該專欄作者,如若文章內容侵犯您的權益,請及時聯系本站刪除。
換一批
延伸閱讀

CPU親和度通過限制進程或線程可以運行的CPU核心集合,使得它們只能在指定的CPU核心上執(zhí)行。這可以減少CPU緩存的失效次數,提高緩存命中率,從而提升系統性能。

關鍵字: Linux 嵌入式

在Linux系統性能優(yōu)化中,內存管理與網絡連接處理是兩大核心領域。vm.swappiness與net.core.somaxconn作為關鍵內核參數,直接影響系統在高負載場景下的穩(wěn)定性與響應速度。本文通過實戰(zhàn)案例解析這兩個...

關鍵字: Linux 內存管理

對于LLM,我使用b谷歌Gemini的免費層,所以唯一的成本是n8n托管。在使用了n8n Cloud的免費積分后,我決定將其托管在Railway上(5美元/月)。然而,由于n8n是開源的,您可以在自己的服務器上托管它,而...

關鍵字: 人工智能 n8n Linux

在Linux系統管理中,權限控制是安全運維的核心。本文通過解析/etc/sudoers文件配置與組策略的深度應用,結合某金融企業(yè)生產環(huán)境案例(成功攔截98.7%的非法提權嘗試),揭示精細化權限管理的關鍵技術點,包括命令別...

關鍵字: Linux 用戶權限 sudoers文件

Linux內核中的信號量(Semaphore)是一種用于資源管理的同步原語,它允許多個進程或線程對共享資源進行訪問控制。信號量的主要作用是限制對共享資源的并發(fā)訪問數量,從而防止系統過載和數據不一致的問題。

關鍵字: Linux 嵌入式

在云計算與容器化技術蓬勃發(fā)展的今天,Linux網絡命名空間(Network Namespace)已成為構建輕量級虛擬網絡的核心組件。某頭部互聯網企業(yè)通過命名空間技術將測試環(huán)境資源消耗降低75%,故障隔離效率提升90%。本...

關鍵字: Linux 云計算

在Linux內核4.18+和主流發(fā)行版(RHEL 8/Ubuntu 20.04+)全面轉向nftables的背景下,某電商平臺通過遷移將防火墻規(guī)則處理效率提升40%,延遲降低65%。本文基于真實生產環(huán)境案例,詳解從ipt...

關鍵字: nftables Linux

在Linux設備驅動開發(fā)中,等待隊列(Wait Queue)是實現進程睡眠與喚醒的核心機制,它允許進程在資源不可用時主動放棄CPU,進入可中斷睡眠狀態(tài),待資源就緒后再被喚醒。本文通過C語言模型解析等待隊列的實現原理,結合...

關鍵字: 驅動開發(fā) C語言 Linux

在Unix/Linux進程間通信中,管道(pipe)因其簡單高效被廣泛使用,但默認的半雙工特性和無同步機制容易導致數據競爭。本文通過父子進程雙向通信案例,深入分析互斥鎖與狀態(tài)機在管道同步中的應用,實現100%可靠的數據傳...

關鍵字: 管道通信 父子進程 Linux

RTOS :RTOS的核心優(yōu)勢在于其實時性。它采用搶占式調度策略,確保高優(yōu)先級任務能夠立即獲得CPU資源,從而在最短時間內完成處理。RTOS的實時性是通過嚴格的時間管理和任務調度算法實現的,能夠滿足對時間敏感性要求極高的...

關鍵字: Linux RTOS
關閉