內存分頁不就夠了?為什么還要分段掠抬?還有段頁式?

你好箫锤,我是 yes雨女。

關于內存訪問你可能聽過分段氛堕,分頁,還有段頁式括儒。

但是為什么要分段锐想?又為什么要分頁?

有了分頁為什么還要分段固逗?

這就需要看一看歷史的發(fā)展藕帜,知曉歷史之后就知道這一切其實都是自然而然的洽故。

這些概念也不是硬塞出來的。

正文

1971 年 11 月 15 日时甚,Intel 推出世界第一塊個人微型處理器 4004(4位處理器)撞秋。

隨后又推出了 8080(8 位處理器)嚣鄙。

那時候訪問內存就只有直白自然的想法,用具體物理地址舅列。

所有的內存訪問就是通過絕對物理地址去訪問的,那時候還沒有段的概念把敞。

段的概念是起源于 8086榨惠,這個 16 位處理器赠橙。

限于當時的技術背景和經濟,寄存器只有 16 位期揪,而地址總線是 20 位凤薛。

那 16 的位的寄存器如何能訪問 20 位的地址?

2 的16 次方如果直著來如何能訪問到 2 的 20 次方所表達的數(shù)速兔?

直著來是不可能的活玲,因此就需要操作一下。

也就是引入段的概念屑柔,讓 CPU 通過「段基地址+段內偏移」來訪問內存珍剑。

有人可能就問你這都只有 16 位招拙,兩個 16 位加起來最多只能表示 17 位呀。

你說的沒錯饰序。

所以再具體一點的計算規(guī)則其實是:段基地址左移 4 位(就是乘16)再加上段內偏移规哪,這樣得到的就是 20 位的地址。

比如現(xiàn)在的要訪問的內存地址是0x05808蝠嘉,那么段基地址可以是 0x0580,偏移量就是 0x0008努酸。

這樣內存的尋址空間就擴大到 20 位了获诈。

至于為什么稱之為段心褐,其實就是因為寄存器只有 16 位一段只能訪問 64 KB,所以需要移動基地址终抽,一段一段的去訪問所有的內存空間桶至。

對了镣屹,專門為分段而生的寄存器為段寄存器,當時里面直接存放段基地址持舆。

不過漸漸地人們就考慮到安全問題伪窖,因為在這個時候程序之間的地址沒有隔離,我的程序可以訪問你的程序地址竹伸,這就很不安全勋篓。

于是在 1982 年 80286 推出時魏割,就有了保護模式。

其實就是 CPU 在訪問地址的時候做了約束拜银,會判斷地址是否在允許的范圍內,會判斷當前的程序對目的地址是否有訪問權限。

搞了個 GDT (全局描述符表)存放所有段描述符疯汁。

段寄存器里面也不是直接放段基地址了幌蚊,而是放了一個叫選擇子的東西溃卡。

大致可以認為就是段描述符的索引,也就是通過這個索引去找到段描述符漩仙,所以叫選擇子犹赖。

這個選擇子里面還有一點屬性峻村。

這個 T1 就是標明要去哪個表找粘昨,而 RPL 就是特權級了,一共分為四層芭析,0 為最高特權級吞瞪,3 為最低特權級。

當?shù)刂吩L問時进统,如果 RPL 的權限低于目標特權級(DPL)時浪听,就會拒絕訪問迹栓,于是就起到了保護的作用。

所以稱之為保護模式酥郭,之前的那種沒有判斷權限的稱之為實模式。

當時 80286 的地址總線已經是 24 位惜姐,但是用于尋址的通用寄存器還是 16 位歹袁,雖然段基地址的位數(shù)已經足夠訪問到 24 位(因為已經放到 GDT 中寝优,且有 24位)。

但是因每次一段只有 64 KB孟抗,這樣訪問就很不方便钻心,需要不斷的更換段基地址扔役,于是 80286 很快就被淘汰,換上了 80386坯钦。

這是 Intel 第一代 32 位處理器侈玄。

除了段寄存器還是 16 位之外序仙,地址總線和寄存器都是 32 位,這就意味著以前為了尋址搞的段機制其實沒用了律秃。

因為單單段內偏移就可以訪問到 4GB 空間治唤,但是為了向前兼容段機制還是保留了下來宾添,段寄存器還是 16 位是因為夠用了柜裸,所以沒必要擴充粱锐。

不過上有政策怜浅,下有對策。

雖說段機制保留了锦爵,但是咱可以“忽悠”著用奥裸,把段基值都設置為 0 湾宙,就用段內偏移地址來訪問內存空間就好了冈绊。

這其實就意味著每個段的起始地址都是一樣的,那就等于不分段了伟恶,這就叫平坦模式博秫。

Linux 就是這樣實現(xiàn)的眶掌。

那為什么要分頁?

因為分段粒度太粗了即寒,導致內存碎片大召噩,不利于管理具滴。

當時加載到內存等于一個段都得搞到內存中,而段的范圍過大施绎,舉個例子。

假設此時你有 200M 內存致稀,此時有 3 個應用在運行俱尼,分別是 LOL遇八、chrome、微信货矮。

此時內存中明明有 30MB 的空閑囚玫,但是網易云加載不進來读规,這內存碎片就有點大了束亏。

然后就得把 chrome 先換到磁盤中,然后再讓 chrome 加載進來到微信的后面定铜,這樣空閑的 30MB 就連續(xù)了雀久,于是網易云就能加載到內存中了帐我。

但是這樣等于要把 50MB 的內存來個反復橫跳麻养,磁盤的訪問太慢了罩锐,所以效率就很低卤唉。

總體而言可以認為分段內存的管理粒度太粗了桑驱,所以隨著 80386 就出來了個分頁管理跛蛋,一個更加精細化的內存管理方式赊级。

簡單地說就是把內存等分成一頁一頁岔绸,每頁 4KB 大小盒揉,按頁為單位來管理內存。

你看按一頁一頁來管理這樣就不用把一段程序都加載進內存羡洛,只需要將用到的頁加載進內存扁掸。

這樣內存的利用率就更高了谴分,能同時運行的程序就更多了镀脂。

并且由于一頁就 4KB薄翅, 所以內存交換的性能問題得以緩解,畢竟只要換一定的頁鼎天,而不需要整個段都換到磁盤中暑竟。

對應的還有個虛擬內存的概念但荤。

分頁機制構造了一個虛擬內存空間腹躁,讓每個進程誤以為自己掌控所有的內存。

再具體一點就是每個進程都有一個頁表哑了,頁表中有物理頁號和屬性弱左,這樣尋址的時候通過頁表就能利用虛擬地址找到對應的物理地址。

屬性用來做權限的一些管理泳梆。

就理解為進程想要內存中的任意一個地址都行优妙,沒問題憎账,反正背地里偷偷的會換成可以用的物理內存地址胞皱。

如果物理內存滿了也沒事,把不常用的內存頁先換到磁盤中雾鬼,即 swap宴树,騰出空間來就好了酒贬,到時候要用再換到內存中。

上面提到的虛擬地址也叫線性地址蠢莺,簡單地說就是通過繞不開的段機制得到線性地址,然后再通過分頁機制轉化得到物理地址零如。

最后

至此我們已經知曉了為什么有分段躏将,又有分頁,還有段頁式埠况。

一開始限于技術和成本所以寄存器的位數(shù)不夠耸携,因此為了擴大尋址范圍搞了個分段訪問內存。

而隨后技術起來了辕翰,位數(shù)都擴充了夺衍,寄存器其實已經可以訪問全部內存空間了,所以分段已經沒用了喜命。

但是為了向前兼容還是保留著分段訪問的形式沟沙,并且隨著軟件的發(fā)展,同時運行各種進程的需求越發(fā)強烈矛紫。

為了更好的管理內存赎瞎,提高內存的利用率和內存交互性能引入了分頁管理。

所以就變成了先分段颊咬,然后再分頁的段頁式务甥。

當然也可以和 Linux 那樣讓每一段的基地址都設為 0 ,這樣就等于“繞開”了段機制喳篇。

至此今天的內容就差不多了敞临,這篇文章沒有深入具體的分段和分頁的細節(jié),之后再作一篇文章來闡述細節(jié)麸澜。

個人能力有限挺尿,如有錯誤請指正?。?

更多文章可看我的文章匯總:https://github.com/yessimida/yes 歡迎 star !


我是 yes炊邦,從一點點到億點點编矾,歡迎在看、轉發(fā)馁害、留言窄俏,我們下篇見。

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末蜗细,一起剝皮案震驚了整個濱河市裆操,隨后出現(xiàn)的幾起案子怒详,更是在濱河造成了極大的恐慌炉媒,老刑警劉巖,帶你破解...
    沈念sama閱讀 221,548評論 6 515
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件昆烁,死亡現(xiàn)場離奇詭異吊骤,居然都是意外死亡,警方通過查閱死者的電腦和手機静尼,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,497評論 3 399
  • 文/潘曉璐 我一進店門白粉,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人鼠渺,你說我怎么就攤上這事鸭巴。” “怎么了拦盹?”我有些...
    開封第一講書人閱讀 167,990評論 0 360
  • 文/不壞的土叔 我叫張陵鹃祖,是天一觀的道長。 經常有香客問我普舆,道長恬口,這世上最難降的妖魔是什么校读? 我笑而不...
    開封第一講書人閱讀 59,618評論 1 296
  • 正文 為了忘掉前任,我火速辦了婚禮祖能,結果婚禮上歉秫,老公的妹妹穿的比我還像新娘。我一直安慰自己养铸,他們只是感情好雁芙,可當我...
    茶點故事閱讀 68,618評論 6 397
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著钞螟,像睡著了一般却特。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上筛圆,一...
    開封第一講書人閱讀 52,246評論 1 308
  • 那天裂明,我揣著相機與錄音,去河邊找鬼太援。 笑死闽晦,一個胖子當著我的面吹牛,可吹牛的內容都是我干的提岔。 我是一名探鬼主播仙蛉,決...
    沈念sama閱讀 40,819評論 3 421
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼碱蒙!你這毒婦竟也來了荠瘪?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 39,725評論 0 276
  • 序言:老撾萬榮一對情侶失蹤赛惩,失蹤者是張志新(化名)和其女友劉穎哀墓,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體喷兼,經...
    沈念sama閱讀 46,268評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡篮绰,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 38,356評論 3 340
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了季惯。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片吠各。...
    茶點故事閱讀 40,488評論 1 352
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖勉抓,靈堂內的尸體忽然破棺而出贾漏,到底是詐尸還是另有隱情,我是刑警寧澤藕筋,帶...
    沈念sama閱讀 36,181評論 5 350
  • 正文 年R本政府宣布纵散,位于F島的核電站,受9級特大地震影響,放射性物質發(fā)生泄漏困食。R本人自食惡果不足惜边翁,卻給世界環(huán)境...
    茶點故事閱讀 41,862評論 3 333
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望硕盹。 院中可真熱鬧符匾,春花似錦、人聲如沸瘩例。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,331評論 0 24
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽垛贤。三九已至焰坪,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間聘惦,已是汗流浹背某饰。 一陣腳步聲響...
    開封第一講書人閱讀 33,445評論 1 272
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留善绎,地道東北人黔漂。 一個月前我還...
    沈念sama閱讀 48,897評論 3 376
  • 正文 我出身青樓,卻偏偏與公主長得像禀酱,于是被迫代替她去往敵國和親炬守。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 45,500評論 2 359

推薦閱讀更多精彩內容