slab著色與cpu硬體快取記憶體
阿新 • • 發佈：2019-01-08
學習LKD的時候，在記憶體管理一章的slab小節中，對於slab的著色只是一筆帶過，並沒有詳細敘述，只好翻看了很多資料，稍微有了點兒概念，其實關鍵在於分清所謂的cache（快取記憶體，包含多個slab塊）和硬體快取記憶體的概念。
slab的設計原理和主體程式碼不難理解，相應的記憶體管理效率提升原理也不難理解，問題在於slab著色的原理和用途。我們都知道slab中，相同大小的物件傾向於存放在硬體快取記憶體內部相同的cache line中，由此產生的問題是，不同slab中，相同大小的物件很可能最終對映到相同的cache line中，當進行鍼對這兩個物件的讀操作時，就出現了兩個物件在cache line和RAM之間來回不停切換的現象，更糟糕的是，剩下的一些cache line可能正在無所事事，著色的主要目的就是避免類似的現象發生。
由於slab是採用空間換時間的方式提高分配效率，因此在slab塊中會存在沒有用處的位元組，我們稱作free，另外，由於要和硬體快取內部的cache line對齊，還存在一個對齊因子的概念，稱作aln，能夠使用的顏色資料為free / aln+1，free個無用位元組被劃分為著色域和著色補償域兩部分，分別位於slab塊的頭和尾，著色域後面緊跟著slab描述符+物件描述符，接下來就是每個物件了，對於物件大小相同的不同slab塊，著色域和著色補償域的大小分別為col x aln和free-col x aln，其中col表示當前slab塊的顏色數，當col x aln=free時，代表顏色數已經分配完，新的物件大小相同的slab生成時，col數目從0開始新一輪的迴圈。這樣，就使得物件大小相同的不同slab塊中的物件擁有不同的位移量，確保它們不會被對映到硬體快取內部相同的cache line中。以上是理想情況，當free < aln時，顏色數只有1個，依然無法避免衝突。
小小總結一下，slab著色功能的高效性是建立在顏色數很多的情況下，但細心的人也會想到，當物件大小相同的slab數目遠遠超過顏色數時，著色仍然避免不了出現衝突。基於這一點考慮，再加上slab的複雜結構和諸如快取佇列等複雜的層次結構帶來的高記憶體佔用，Linux核心小組在2.6.23以及之後的核心版本中，採用slub演算法替代了slab演算法，按照Linux核心小組人員的說法，slub較slab提升了5%~10%的效能並減少了50%的核心快取佔用，也就是說，不僅僅從時間，而且從空間上都較slab演算法有了改善，slub完全相容slab的介面，核心的其他模組無需修改程式碼就可以從新的核心快取分配演算法中收益。
slab的設計原理和主體程式碼不難理解，相應的記憶體管理效率提升原理也不難理解，問題在於slab著色的原理和用途。我們都知道slab中，相同大小的物件傾向於存放在硬體快取記憶體內部相同的cache line中，由此產生的問題是，不同slab中，相同大小的物件很可能最終對映到相同的cache line中，當進行鍼對這兩個物件的讀操作時，就出現了兩個物件在cache line和RAM之間來回不停切換的現象，更糟糕的是，剩下的一些cache line可能正在無所事事，著色的主要目的就是避免類似的現象發生。
由於slab是採用空間換時間的方式提高分配效率，因此在slab塊中會存在沒有用處的位元組，我們稱作free，另外，由於要和硬體快取內部的cache line對齊，還存在一個對齊因子的概念，稱作aln，能夠使用的顏色資料為free / aln+1，free個無用位元組被劃分為著色域和著色補償域兩部分，分別位於slab塊的頭和尾，著色域後面緊跟著slab描述符+物件描述符，接下來就是每個物件了，對於物件大小相同的不同slab塊，著色域和著色補償域的大小分別為col x aln和free-col x aln，其中col表示當前slab塊的顏色數，當col x aln=free時，代表顏色數已經分配完，新的物件大小相同的slab生成時，col數目從0開始新一輪的迴圈。這樣，就使得物件大小相同的不同slab塊中的物件擁有不同的位移量，確保它們不會被對映到硬體快取內部相同的cache line中。以上是理想情況，當free < aln時，顏色數只有1個，依然無法避免衝突。
小小總結一下，slab著色功能的高效性是建立在顏色數很多的情況下，但細心的人也會想到，當物件大小相同的slab數目遠遠超過顏色數時，著色仍然避免不了出現衝突。基於這一點考慮，再加上slab的複雜結構和諸如快取佇列等複雜的層次結構帶來的高記憶體佔用，Linux核心小組在2.6.23以及之後的核心版本中，採用slub演算法替代了slab演算法，按照Linux核心小組人員的說法，slub較slab提升了5%~10%的效能並減少了50%的核心快取佔用，也就是說，不僅僅從時間，而且從空間上都較slab演算法有了改善，slub完全相容slab的介面，核心的其他模組無需修改程式碼就可以從新的核心快取分配演算法中收益。