天天看點

[轉帖]Linux核心為大規模支援100Gb/s網卡準備好了嗎?并沒有Linux核心為大規模支援100Gb/s網卡準備好了嗎?并沒有

Linux核心為大規模支援100Gb/s網卡準備好了嗎?并沒有

之前用 千兆的機器 下載下傳速度 一般隻能到 50MB 左右 沒法更高 萬兆的話 可能也就是 200MB左右的速度 很難更高 不知道後續的伺服器 會不會 能夠提升一下 

之前坐着說到了 120nm 的時間 發送一個包 記得CPU的指令周期是 1-3nm左右 
個記憶體的時間差不多了

不知道RDMA等的方式 可不可能完成相應的高吞吐量的處理.

原作者部落格
https://blog.csdn.net/zhoukejun/article/details/4153266      

  版權聲明:本文為部落客原創,無版權,未經部落客允許可以随意轉載,無需注明出處,随意修改或保持可作為原創! https://blog.csdn.net/dog250/article/details/86756635

又是大年初一,和過去三十多年的新年一樣,無聊,消沉,吃不好飯,盼着上班(小時候是盼着開學…)…

事實上,不僅僅是Linux核心,幾乎所有的 現代作業系統 都沒有為支援100Gb/s做好準備。

這是一個變革的年代,現代作業系統 已經不再 現代!

我們回望一下類似Unix/Linux,Windows NT這些作業系統是如何被稱作 現代 的。嗯,是因為虛拟記憶體系統。

是 隔離的位址空間 讓作業系統一下子進入了現代社會。在此之前,作業系統都是譚浩強書裡寫的那種一旦操作空指針就會系統崩潰的系統。

自打作業系統成為現代作業系統後,貌似它就沒有再有過突破性的進化,但是其周邊,确實翻天覆地了。

先看CPU和系統架構,先是其主頻的瘋漲,然後又是多核架構。主頻增加這個對于作業系統核心來講是好事,在機關時間内能多執行很多指令,這完全是一個打雞血的過程。然而多核心架構就讓幾乎所有的作業系統核心有點開始吃力應對了。其對資料同步的解法中,往往都是見招拆招地加鎖。

多核心架構對系統性能的作用力和主頻增加的作用力方向是相反的,如果主頻的增加讓CPU在機關時間執行了更多的指令,那麼多核之間的溝通成本抵消了這個主頻提升帶來的收益,因為同步成本是高昂的。

多核心架構重演了 人月神話。

最後的結果就是,支援SMP多核架構的作業系統核心,其實就是給當年引入虛拟記憶體時的現代作業系統全部挂滿了枷鎖而已。單就作業系統核心本身而言,它更慢了,而不是更快了!

意思是說,多核心架構下,單獨的CPU上,作業系統的執行效率要比單核架構下作業系統的執行效率更低了!核數越多,溝通同步成本越大,最終讓性能/核心數曲線上凸!

而溝通同步的方式,無外乎就是,鎖!

是以說,鎖是阻止作業系統性能多核擴充性伸縮性的罪魁禍首!

事實上,Linux核心也好,UNIX也好,Windows NT也好,根本就不是為多核心架構而設計的,它們隻是 簡單适應了SMP而已。

作業系統雖然是現代的, 但是卻不是當代的! (我記得上國小和國中那會兒,老師說過現代和當代的差別)

在現代作業系統發展停滞不前的時候,硬體卻沒有閑着。

100Gb/s網卡的意思是說, 如果有100Gb的資料在緩沖區裡,它可以在1秒中把它們全部發送出去。但問題是, 作業系統有能力在1秒鐘内準備好100Gb的資料嗎?

我們知道,在我們對作業系統的傳統認知中,資料的源頭來自于使用者态緩沖區,經由作業系統核心協定棧,将資料怼到網卡緩存區。我們可以簡單測算一下,作業系統的核心協定棧有沒有能力1秒鐘往網卡怼100Gbit的資料。

這裡有幾個簡單的統計資料統計點,擷取這些資料的方法:

  • 在tcp_write_xmit函數的while循環裡打點,看看發送一個skb需要多久;
  • 使用pktgen類似的機制,測算單包發送延時。

在如今常見的1Gb/s的網卡上發包測算,平均約4微秒發送一個Full Mss的包,貌似Linux核心對于千兆網卡應對的還不錯,但這并不意味着它應對10Gb/s,40Gb/s,100Gb/s這些發送速率時,是可以線性擴充的!

簡單反算,100Gb/s需要單包發送延時在120納秒以内,我們隻需要測算一下120納秒夠不夠核心協定棧處理一個資料包就可以了。

納秒,這是一個cache級别的時間,如果發生了一次cache命中,至少可以節省20到30納秒的時間,但是反過來如果很不幸cache missing了,那麼就要在120納秒中扣除20到30納秒,這樣就剩下90納秒了。

該重頭戲了:

  • 一次spinlock需要20納秒左右的時間;
  • 一次記憶體配置設定需要大概60納秒的時間;

很不幸,沒有時間剩下來了。以上的測算還是基于64位元組的小包,絲毫沒有包括真正的處理開銷!而我們知道,協定棧處理過程中,有超級多的協定邏輯…120納秒遠遠不夠!

在協定棧處理資料包并發送的過程中,記憶體配置設定和記憶體操作将會引入巨大的延時,這十有八九又會牽扯到cache missing!

從另一個角度看,Linux核心作為一個通用作業系統核心,顯然并沒有針對單獨的特性做極端的性能優化,這個意義上,我不是說它沒有為大規模支援100Gb/s網卡做好準備,而是它可能根本就沒有準備在支援這種高速網卡的競賽中取得勝利!這方面你可以和David Miller交流一下,看看在他看來,代碼的可維護性,簡潔性,統一處理這些和極端的性能優勢相比,哪個更重要。

不過,無論如何,Linux核心,Windows NT之類的OS核心在多核心架構下無法線性擴充,這确實是阻礙其從 現代作業系統 進化到 當代作業系統 的路易十六!

轉載于:https://www.cnblogs.com/jinanxiaolaohu/p/10358632.html

又是大年初一,和過去三十多年的新年一樣,無聊,消沉,吃不好飯,盼着上班(小時候是盼着開學…)…

事實上,不僅僅是Linux核心,幾乎所有的 現代作業系統 都沒有為支援100Gb/s做好準備。

這是一個變革的年代,現代作業系統 已經不再 現代!

我們回望一下類似Unix/Linux,Windows NT這些作業系統是如何被稱作 現代 的。嗯,是因為虛拟記憶體系統。

是 隔離的位址空間 讓作業系統一下子進入了現代社會。在此之前,作業系統都是譚浩強書裡寫的那種一旦操作空指針就會系統崩潰的系統。

自打作業系統成為現代作業系統後,貌似它就沒有再有過突破性的進化,但是其周邊,确實翻天覆地了。

先看CPU和系統架構,先是其主頻的瘋漲,然後又是多核架構。主頻增加這個對于作業系統核心來講是好事,在機關時間内能多執行很多指令,這完全是一個打雞血的過程。然而多核心架構就讓幾乎所有的作業系統核心有點開始吃力應對了。其對資料同步的解法中,往往都是見招拆招地加鎖。

多核心架構對系統性能的作用力和主頻增加的作用力方向是相反的,如果主頻的增加讓CPU在機關時間執行了更多的指令,那麼多核之間的溝通成本抵消了這個主頻提升帶來的收益,因為同步成本是高昂的。

多核心架構重演了 人月神話。

最後的結果就是,支援SMP多核架構的作業系統核心,其實就是給當年引入虛拟記憶體時的現代作業系統全部挂滿了枷鎖而已。單就作業系統核心本身而言,它更慢了,而不是更快了!

意思是說,多核心架構下,單獨的CPU上,作業系統的執行效率要比單核架構下作業系統的執行效率更低了!核數越多,溝通同步成本越大,最終讓性能/核心數曲線上凸!

而溝通同步的方式,無外乎就是,鎖!

是以說,鎖是阻止作業系統性能多核擴充性伸縮性的罪魁禍首!

事實上,Linux核心也好,UNIX也好,Windows NT也好,根本就不是為多核心架構而設計的,它們隻是 簡單适應了SMP而已。

作業系統雖然是現代的, 但是卻不是當代的! (我記得上國小和國中那會兒,老師說過現代和當代的差別)

在現代作業系統發展停滞不前的時候,硬體卻沒有閑着。

100Gb/s網卡的意思是說, 如果有100Gb的資料在緩沖區裡,它可以在1秒中把它們全部發送出去。但問題是, 作業系統有能力在1秒鐘内準備好100Gb的資料嗎?

我們知道,在我們對作業系統的傳統認知中,資料的源頭來自于使用者态緩沖區,經由作業系統核心協定棧,将資料怼到網卡緩存區。我們可以簡單測算一下,作業系統的核心協定棧有沒有能力1秒鐘往網卡怼100Gbit的資料。

這裡有幾個簡單的統計資料統計點,擷取這些資料的方法:

  • 在tcp_write_xmit函數的while循環裡打點,看看發送一個skb需要多久;
  • 使用pktgen類似的機制,測算單包發送延時。

在如今常見的1Gb/s的網卡上發包測算,平均約4微秒發送一個Full Mss的包,貌似Linux核心對于千兆網卡應對的還不錯,但這并不意味着它應對10Gb/s,40Gb/s,100Gb/s這些發送速率時,是可以線性擴充的!

簡單反算,100Gb/s需要單包發送延時在120納秒以内,我們隻需要測算一下120納秒夠不夠核心協定棧處理一個資料包就可以了。

納秒,這是一個cache級别的時間,如果發生了一次cache命中,至少可以節省20到30納秒的時間,但是反過來如果很不幸cache missing了,那麼就要在120納秒中扣除20到30納秒,這樣就剩下90納秒了。

該重頭戲了:

  • 一次spinlock需要20納秒左右的時間;
  • 一次記憶體配置設定需要大概60納秒的時間;

很不幸,沒有時間剩下來了。以上的測算還是基于64位元組的小包,絲毫沒有包括真正的處理開銷!而我們知道,協定棧處理過程中,有超級多的協定邏輯…120納秒遠遠不夠!

在協定棧處理資料包并發送的過程中,記憶體配置設定和記憶體操作将會引入巨大的延時,這十有八九又會牽扯到cache missing!

從另一個角度看,Linux核心作為一個通用作業系統核心,顯然并沒有針對單獨的特性做極端的性能優化,這個意義上,我不是說它沒有為大規模支援100Gb/s網卡做好準備,而是它可能根本就沒有準備在支援這種高速網卡的競賽中取得勝利!這方面你可以和David Miller交流一下,看看在他看來,代碼的可維護性,簡潔性,統一處理這些和極端的性能優勢相比,哪個更重要。

不過,無論如何,Linux核心,Windows NT之類的OS核心在多核心架構下無法線性擴充,這确實是阻礙其從 現代作業系統 進化到 當代作業系統 的路易十六!

繼續閱讀