多核心Linux核心路徑優化的不二法門之-slab與夥伴系統
作為這個系列的第一篇,我先來描述一下slab系統。因為近些天有和同事,朋友討論過這個主題,而且覺得這個主題還算比較典型,所以就作為第一篇了。其實按照作業系統理論來講,程式管理應該更加重要些,按照我自己的興趣來講,IO管理以及TCP/IP協議棧會更加有分量,關於這些內容,我會陸續給出。
Linux核心的slab來自一種很簡單的思想,即事先準備好一些會頻繁分配,釋放的資料結構。然而標準的slab實現太複雜且維護開銷巨大,因此便分化出了更加小巧的slub,因此本文討論的就是slub,後面所有提到slab的地方,指的都是slub。另外又由於本文主要描述核心優化方面的內容,並不是基本原理介紹,因此想了解slab細節以及程式碼實現的請自行百度或者看原始碼。單CPU上單純的slab
下圖給出了單CPU上slab在分配和釋放物件時的情景序列:
擴充套件到多核心CPU
現在我們簡單的將上面的模型擴充套件到多核心CPU,同樣差不多的分配序列如下圖所示:
多CPU無鎖化並行化操作的直接思路-複製給每個CPU一套相同的資料結構。
不二法門就是增加“每CPU變數”。對於slab而言,可以擴充套件成下面的樣子:
問題
首先,我們來看一個簡單的問題,如果單獨的某個CPU的slab快取沒有物件可分配了,但是其它CPU的slab快取仍有大量空閒物件的情況,如下圖所示:
在繼續之前,首先要明確的是,我們需要在CPU間均衡slab,並且這些必須靠slab內部的機制自行完成,這個和程式在CPU間負載均衡是完全不同的,對程式而言,擁有一個核心排程機制,比如基於時間片,或者虛擬時鐘的步進速率等,但是對於slab,完全取決於使用者自身,只要物件仍然在使用,就不能剝奪使用者繼續使用的權利,除非使用者自己釋放。因此slab的負載均衡必須設計成合作型的,而不是搶佔式的。
好了。現在我們知道,從夥伴系統重新分配一個page(s)並不是一個好主意,它應該是最終的決定,在執行它之前,首先要試一下別的路線。
現在,我們引出第二個問題,如下圖所示:
問題的解決-分層slab cache
無級變速總是讓人嚮往。如果一個CPU的slab快取滿了,直接去搶同級別的別的CPU的slab快取被認為是一種魯莽且不道義的做法。那麼為何不設定另外一個slab快取,獲取它裡面的物件不像直接獲取CPU的slab快取那麼簡單且直接,但是難度卻又不大,只是稍微增加一點消耗,這不是很好嗎?事實上,CPU的L1,L2,L3 cache不就是這個方案設計的嗎?這事實上已經成為cache設計的不二法門。這個設計思想同樣作用於slab,就是Linux核心的slub實現。
現在可以給出概念和解釋了。
Level 1 slab cache:一個空閒物件連結串列,每個CPU一個的獨享cache,分配釋放物件無需加鎖。
Level 2 slab cache:一個空閒物件連結串列,每個CPU一個的共享page(s) cache,分配釋放物件時僅需要鎖住該page(s),與Level 1 slab cache互斥,不互相包容。
Level 3 slab cache:一個page(s)連結串列,每個NUMA NODE的所有CPU共享的cache,單位為page(s),獲取後被提升到對應CPU的Level 1 slab cache,同時該page(s)作為Level 2的共享page(s)存在。
共享page(s):該page(s)被一個或者多個CPU佔有,每一個CPU在該page(s)上都可以擁有互相不充圖的空閒物件連結串列,該page(s)擁有一個唯一的Level 2 slab cache空閒連結串列,該連結串列與上述一個或多個Level 1 slab cache空閒連結串列亦不衝突,多個CPU獲取該Level 2 slab cache時必須爭搶,獲取後可以將該連結串列提升成自己的Level 1 slab cache。
該slab cache的圖示如下:
2個場景
對於常規的物件分配過程,下圖展示了其細節:
夥伴系統
前面我們簡短的體會了Linux核心的slab設計,不宜過長,太長了不易理解.但是最後,如果Level 3也沒有獲取page(s),那麼最終會落到終極的夥伴系統。夥伴系統是為了防記憶體分配碎片化的,所以它儘可能地做兩件事:
1).儘量分配儘可能大的記憶體
2).儘量合併連續的小塊記憶體成一塊大記憶體
我們可以通過下面的圖解來理解上面的原則:
鑑於slab快取物件大多數都是不超過1個頁面的小結構(不僅僅slab系統,超過1個頁面的記憶體需求相比1個頁面的記憶體需求,很少),因此會有大量的針對1個頁面的記憶體分配需求。從夥伴系統的分配原理可知,如果持續大量分配單一頁面,會有大量的order大於0的頁面分裂成單一頁面,在單核心CPU上,這不是問題,但是在多核心CPU上,由於每一個CPU都會進行此類分配,而夥伴系統的分裂,合併操作會涉及大量的連結串列操作,這個鎖開銷是巨大的,因此需要優化!
Linux核心對夥伴系統針對單一頁面的分配需求採取的批量分配“每CPU單一頁面快取”的方式!
每一個CPU擁有一個單一頁面快取池,需要單一頁面的時候,可以無需加鎖從當前CPU對應的頁面池中獲取頁面。而當池中頁面不足時,系統會批量從夥伴系統中拉取一堆頁面到池中,反過來,在單一頁面釋放的時候,會擇優將其釋放到每CPU的單一頁面快取中。
為了維持“每CPU單一頁面快取”中頁面的數量不會太多或太少(太多會影響夥伴系統,太少會影響CPU的需求),系統保持了兩個值,當快取頁面數量低於low值的時候,便從夥伴系統中批量獲取頁面到池中,而當快取頁面數量大於high的時候,便會釋放一些頁面到夥伴系統中。
小結
多CPU作業系統核心中,關鍵的開銷就是鎖的開銷。我認為這是一開始的設計導致的,因為一開始,多核CPU並沒有出現,單核CPU上的共享保護幾乎都是可以用“禁中斷”,“禁搶佔”來簡單實現的,到了多核時代,作業系統同樣簡單平移到了新的平臺,因此同步操作是在單核的基礎上後來新增的。簡單來講,目前的主流作業系統都是在單核年代創造出來的,因此它們都是順應單核環境的,對於多核環境,可能它們一開始的設計就有問題。不管怎麼說,優化操作的不二法門就是禁止或者儘量減少鎖的操作。隨之而來的思路就是為共享的關鍵資料結構建立"每CPU的快取“,而這類快取分為兩種型別:
1).資料通路快取。
比如路由表之類的資料結構,你可以用RCU鎖來保護,當然如果為每一個CPU都建立一個本地路由表快取,也是不錯的,現在的問題是何時更新它們,因為所有的快取都是平級的,因此一種批量同步的機制是必須的。2).管理機制快取。
比如slab物件快取這類,其生命週期完全取決於使用者,因此不存在同步問題,然而卻存在管理問題。採用分級cache的思想是好的,這個非常類似於CPU的L1/L2/L3快取,採用這種平滑的開銷逐漸增大,容量逐漸增大的機制,並配合以設計良好的換入/換出等演算法,效果是非常明顯的。相關文章
- Linux優化之IO子系統監控與調優Linux優化
- xenomai核心解析之雙核系統呼叫(一)AI
- Linux系統優化部分核心引數調優中文註釋Linux優化
- Linux 效能優化之 IO 子系統Linux優化
- 深度剖析 Linux 夥伴系統的設計與實現Linux
- 解決系統盤空間不足的不二法寶
- Linux 系統優化Linux優化
- Linux系統配置(系統優化)Linux優化
- 【基礎知識】Linux系統的安全與優化Linux優化
- MySQL優化之系統變數優化MySql優化變數
- Linux核心優化之TCP相關引數Linux優化TCP
- 分享Linux系統快速入門法Linux
- 寫給正在入坑linux系統的夥伴Linux
- linux系統優化指令碼Linux優化指令碼
- 熟悉Linux系統的安全和優化Linux優化
- Linux核心優化詳解Linux優化
- Linux系統與Windows系統的不同之處LinuxWindows
- Linux系統安全常規優化Linux優化
- 【原創】解BUG-xenomai核心與linux核心時間子系統之間存在漂移AILinux
- Linux 核心引數優化(for oracle)Linux優化Oracle
- 學生資訊管理系統之優化優化
- 滴滴Ceph分散式儲存系統優化之鎖優化分散式優化
- Linux的配置與優化Linux優化
- linux核心--子系統Linux
- 系統的優化思路優化
- Linux系統效能調優之效能分析Linux
- Linux作業系統的優勢是什麼?Linux入門Linux作業系統
- Linux 檔案系統之入門必看!Linux
- 《Linux核心分析》 之 作業系統是如何工作的。2Linux作業系統
- 《Linux核心修煉之道》精華分享與討論(15)——子系統的初始化:核心選項解析薦Linux
- (mysql優化-3) 系統優化MySql優化
- linux核心引數優化重要項Linux優化
- Windows系統之XP應用優化指南Windows優化
- linux 頁框管理(二) 夥伴系統演算法Linux演算法
- 從核心原始碼看 slab 記憶體池的建立初始化流程原始碼記憶體
- (3)Linux效能調優之Linux檔案系統Linux
- 多租戶系統的核心概念模型模型
- slab原始碼分析--從slab初始化說起原始碼