CPU快取記憶體與反置頁表 排程的科普

2021-09-25 01:34:17 字數 2796 閱讀 5060

雖然我喜歡分級頁表,但是反置頁表才是更加自然的方式。之所以叫做反置頁表,大概是因為它顛倒我們常規理解的定址:

而反置頁表將上述問題轉換成了:

嗯,是個問句,那麼就難免牽扯進去諸如搜尋的操作了。

由於描述全部物理記憶體全系統一張表就足夠,最不濟的方式就是把這一張表遍歷搜尋一遍唄。於是就會出現一些論調,比如雖然反置頁表效率太低,不太適合硬體實現等等。

但是且慢,其實我們早就已經在跟類似反置頁表的機制打交道了,那就是cpu快取記憶體。你可以質疑反置頁表的實現尚有缺陷,但是質疑反置頁表的本質,便無遺是在質疑cpu快取記憶體機制本身。

這便就是反置頁表要解決的問題。完全一致啊!

下面的問題是,如何把cpu快取記憶體的那套實現機制,借鑑給反置頁表。

顯然,直接照搬是困難的,因為它們雖然機制完全類似,但是卻是處理其大小具有數量級差異的位址空間,這本身就是乙個大的問題。

硬體並行查詢128k是容易實現的,但是硬體並行查詢128g便不是了。這裡不展開細節了,關於這個話題可以參考一本非常不錯的書:

《現代體系結構上的unix系統:核心程式設計師的對稱多處理和快取技術》

這本書是我2023年11月份去鵝廠上班前讀的,沒有讀完,後來工作內容與此無關了,就沒有繼續,現在又翻到了它,索性接著讀下去吧。

對了,反置頁表類似於該書第4章描述的帶有程序鍵值的虛擬快取記憶體(程序切換不用flush的那種…),程序鍵值也就是程序的pid了。

另外還有乙個tip就是,反置頁表不能使用快取記憶體的組相聯機制,但是卻非常類似全相聯,why?

因為組相聯完全依賴記憶體訪問的時間區域性性和空間區域性性,這一點亙古不變,然而,物理記憶體向虛擬記憶體的對映卻不滿足這種區域性性,或者說不完全滿足。

物理記憶體管理要解決的問題除了區域性性帶來的訪問效率問題之外,還要解決空間利用率問題,即碎片問題,此外,物理記憶體全部程序共享,所以還需要在所有程序之間滿足公平性需求:

區域性性需求。

碎片最小化需求。

公平性需求。

以linux核心的夥伴系統為例,它就是為此而準備的,而區域性性問題則由夥伴系統上層的slab/slub機制來保證。

也就是說,物理頁面的分配並不一定按照cpu的mmu期望或者說至少理解的那樣去進行,中間隔了好幾個抽象層。所以說:

這不就是全相聯嘛。

如果就此結束本文,那就真的顯得連吹水都不是了,所以,接下來還是要吹水的。

再說說反置頁表的實現,幾乎可以肯定不能用cpu快取記憶體的實現方案,因為位址空間差異太大,過於昂貴。如果純軟體化,那效率又過於低下,如何來權衡?

這裡不談tlb,那是另乙個話題。

這裡介紹乙個思路,用tcam加以改造。

既然不用cpu快取記憶體的方案,那麼用路由表的方案總可以,因為路由表條目的數量級和物理頁面條目數的數量級相當。

2023年寫過一篇關於此的文章:

硬體路由**原理**

就是這個思路。

反置頁表就說到這了。下面說說cpu快取記憶體和排程之間的合離。

假設沒有快取記憶體,現代多核系統上的排程要容易太多。就是乙個簡單的多處理器空間分配問題:

正是有了快取記憶體,才讓多核的概念從多處理器中剝離了出來(當然,除了快取記憶體,還有運算單元共享,流水線等因素),並且以快取的細節示區別。快取記憶體的組織方式,極大地影響了程序排程的策略。

多核架構一般可以按照核,處理器,封裝等分為三個或者多個層次,比如下面的二級結構:

\

我們說cpu

1cpu_1

cpu1​和cpu

2cpu_2

cpu2

​是同乙個處理器的兩個核心,同樣cpu

3cpu_3

cpu3​和cpu

4cpu_4

cpu4

​是另乙個處理的兩個核心。

按照記憶體訪問區域性性以及成本/效率權衡而普適的分層儲存原則,一般的快取是如下組織的:

由於以上覆雜但清晰的快取記憶體組織,考慮到命中快取記憶體的巨大收益,多核系統的程序,特別是執行緒排程就不得不盡量滿足以下的約束:

於是,排程策略就比較明確了:

以上的策略要是真較真起來,可以寫一本書,但是我這裡恰恰要說的是,過於僅僅關注上述的策略,那便是捨本逐末,反客為主了。

描述結論,上述的最大化快取記憶體利用率只是自上而下的使用者視角下的最佳排程策略,還有乙個自下而上的系統視角,這個視角下認為的最佳排程策略乃是最大化cpu利用率,即吞吐率最優。換句話說,無論是要最大化快取利用率,還是最大化吞吐,都只是問題,而非排程本身,所以它們都是要解決的,但解決方案並非就是排程策略或者說排程演算法,排程是乙個總體上的方案,而不是為了解決某個特定的問題。

我想linux核心也許就是過於關注最大化快取記憶體利用率了,所以才忽略了負載均衡演算法中除了和快取記憶體相關的策略之外的所有一切。才有了下面的這篇文章:

douban鏈結是:

沒啥評價,應該現在也買不到了。看了目錄,你可能會說,這些早就已經過時了…確實,早就過時了,這本書出版時,2.5g/3g都還是未來,更別說跟現在比了。我是在2023年底讀此書的,當時剛畢業沒多久,一腔熱血投入到了voip,ngn軟交換中,直到現在,沒事還會掃兩眼asterisk的動態…

這麼多年了,昨天收拾書,找到了這本,夜深的時候又過了一遍,恍若昨日!然而,過了十幾年了,這本書中提到的一些底層設施,底層技術,以及組織這些基礎設施的方法,運營商的策略,萬變不離其宗。強烈推薦!

浙江溫州皮鞋溼,下雨進水不會胖。

每CPU頁框快取記憶體

在 linux頁框級記憶體管理處理細節 一篇博文中,我們談到核心呼叫alloc pages等系列函式分配乙個或一片連續的頁框。這一系列函式本質上是使用夥伴演算法從指定zone t中取到乙個或一片連續的空閒的頁框。正如我們將在以後重點博文 slab分配器 所看到的,核心經常請求和釋放單個頁框。為了提公...

7每CPU頁框快取記憶體

在 linux頁框級記憶體管理處理細節 一篇博文中,我們談到核心呼叫alloc pages等系列函式分配乙個或一片連續的頁框。這一系列函式本質上是使用夥伴演算法從指定zone t中取到乙個或一片連續的空閒的頁框。正如我們將在以後重點博文 slab分配器 所看到的,核心經常請求和釋放單個頁框。為了提公...

無法寫入快取記憶體 記憶體與CPU的快取記憶體的關係

我們個人pc都有乙個叫做記憶體的硬體,有4g 8g 16g不等的容量。但我們的cpu執行時執行的指令並不是直接從記憶體中獲取,而是從cpu自身的快取記憶體中獲得指令並執行,指令執行完畢再寫回快取,然後待到特定的時機才把資料在寫回主記憶體。那cpu是如何將比自己容量大的多的記憶體放進自己的快取記憶體中...