linux內存分頁
計算機的存儲空間問題相信大部分的管理員都有不同的處理方式。今天我們就一起來了解一下，在linux系統中，交換空間的具體使用情況是什麼。希望通過對本文的閱讀，大家對於linux系統有更多的了解，下面就開始今天的主要內容吧。
交換空間
交換空間是現代Linux系統中的二種內存類型。交換空間的主要功能是當全部的RAM被佔用並且需要更多內存時，用磁碟空間代替RAM內存。
例如，假設你有一個8GBRAM的計算機。如果你啟動的程序沒有填滿RAM，一切都好，不需要交換。假設你在處理電子表格，當添加更多的行時，你電子表格會增長，加上所有正在運行的程序，將會佔用全部的RAM。如果這時沒有可用的交換空間，你將不得不停止處理電子表格，直到關閉一些其他程序來釋放一些RAM。
內核使用一個內存管理程序來檢測近沒有使用的內存塊(內存頁)。內存管理程序將這些相對不經常使用的內存頁交換到硬碟上專門指定用於「分頁」或交換的特殊分區。這會釋放RAM，為輸入電子表格更多數據騰出了空間。那些換出到硬碟的內存頁面被內核的內存管理代碼跟蹤，如果需要，可以被分頁回RAM。
Linux計算機中的內存總量是RAM+交換分區，交換分區被稱為虛擬內存.
Linux交換分區類型
Linux提供了兩種類型的交換空間。默認情況下，大多數Linux在安裝時都會創建一個交換分區，但是也可以使用一個特殊配置的文件作為交換文件。電腦培訓http://www.kmbdqn.cn/發現交換分區顧名思義就是一個標准磁碟分區，由mkswap命令指定交換空間。
如果沒有可用磁碟空間來創建新的交換分區，或者卷組中沒有空間為交換空間創建邏輯卷，則可以使用交換文件。這只是一個創建好並預分配指定大小的常規文件。然後運行mkswap命令將其配置為交換空間。除非絕對必要，否則我不建議使用文件來做交換空間。(LCTT譯註：Ubuntu近來的版本採用了交換文件而非交換空間，所以我對於這種說法保留看法)
Ⅱ Linux內存系統
維基網路——虛擬內存定義
All about Linux swap space
Linux將物理RAM （Random Access Memory） 劃分為稱為頁面的內存塊。交換是將一頁內存復制到硬碟上的預配置空間（稱為交換空間）以釋放改內存頁面上的過程。物理內存和交換空間的組合就是可用的虛擬內存量。
虛擬內存的那點事兒
進程是與其他進程共享CPU和內存資源的。為了有效的管理內存並減少出錯，現代操作系統提供了一種對主存的抽象概念，即：虛擬內存（ Virtual Memory ）。 虛擬內存為每個進程提供一個一致的，私有的地址空間，每個進程擁有一片連續完整的內存空間。
正如 維基網路 所說，虛擬內存不只是「使用硬碟空間來擴展內存」的技術。 虛擬內存的重要意義是它定義了一個連續的虛擬地址空間， 使得程序編寫難度降低。並且， 把內存擴展到硬碟空間只是使用虛擬內存的必然結果，虛擬內存空間會存在硬碟中，並且會被全部放入內存中緩沖（按需），有的操作系統還會在內存不夠的情況下，將一進程的內存全部放入硬碟空間中，並在切換到進程時再從硬碟讀取 （這也是Windows會經常假死的原因...）。
虛擬內存主要提供了如下三個重要的能力：
內存通常被組織為一個由M個連續的位元組大小的單元組成的數組。每個位元組都有一個唯一的物理地址 （Physical Address PA） ，作為到數組的索引。
CPU訪問內存最簡單直接的方法就是使用物理地址，這種定址方式稱為 物理定址 。
現代計算機使用的是一種被稱為虛擬定址 （Virtual Addressing） 的定址方式。 使用虛擬定址，CPU需要將虛擬地址翻譯成物理地址，這樣才能訪問到真實的物理內存。
虛擬定址需要硬體與操作系統之間相互合作。 CPU中含有一個被稱為內存管理單元 （Memory Management Unit，MMU） 的硬體，它的功能是將虛擬地址轉換稱為物理地址，MMU需要藉助存放在內存中的 頁表 來動態翻譯虛擬地址，該頁表由操作系統管理。
分頁表是一種數據結構，它用於計算機操作系統中虛擬內存系統，其存儲了虛擬地址到物理地址之間的映射。虛擬地址在訪問進程中是唯一的，而物理地址在硬體（比如內存）中是唯一的。
在操作系統中使用 虛擬內存 ，每個進程會認為使用一塊大的連續的內存，事實上，每個進程的內存散布在 物理內存 的不同區域。或者可能被調出到備份存儲中（一般是硬碟）。當一個進程請求自己的內存，操作系統負責把程序生成的虛擬地址，映射到實際存儲的物理內存上。操作系統在 分頁表 中存儲虛擬地址到物理地址的映射。每個映射被稱為 分頁表項（page table entry ,PTE） 。
在一個簡單的地址空間方案中，由虛擬地址定址的頁與物理內存中的幀之間的關系。物理內存可以包含屬於許多進程的頁。如果不經常使用，或者物理內存已滿，可以將頁面分頁到磁碟。在上圖中，並非所有頁面都在物理內存中。
虛擬地址到物理地址的轉換（即虛擬內存的管理）、內存保護、CPU高速緩存的控制。
現代的內存管理單元是以 頁 的方式，分割虛擬地址空間（處理器使用的地址范圍）的；頁的大小是2的n次方，通常為幾KB（位元組）。地址尾部的n位（頁大小的2的次方數）作為頁內的偏移量保持不變。其餘的地址位（address）為（虛擬）頁號。
內存管理單元通常藉助一種叫做轉譯旁觀緩沖器（Translation Lookaside Buffer，TLB）和相聯高速緩存來將虛擬頁號轉換為物理頁號。當後備緩沖器中沒有轉換記錄時，則使用一種較慢的機制，其中包括專用硬體的數據結構或軟體輔助手段。這個數據結構稱為 分頁表 ，頁表中的數據叫做 分頁表項 （page table entry PTE）。物理頁號結合頁偏移量便提供了完整的物理地址。
頁表 或 轉換後備緩沖器數據項應該包括的信息有：
有時候，TLB和PTE會 禁止對虛擬頁訪問 ，這可能是因為沒有RAM與虛擬頁相關聯。如果是這種情況，MMU將向CPU發出頁錯誤的信號，操作系統將進行處理，也許會尋找RAM的空白幀，同時建立一個新的PTE將之映射到所請求的虛擬地址。如果沒有空閑的RAM，可能必須關閉一個已經存在的頁面，使用一些替換演算法，將之保存到磁碟中（這被稱為頁面調度）。
當需要將虛擬地址轉換為物理地址時，首先搜索TLB，如果找到匹配（TLB）命中，則返回物理地址並繼續存儲器訪問。然而，如果沒有匹配（稱為TLB未命中），則MMU或操作系統TLB未命中處理器通常會查找 頁表 中的地址映射以查看是否存在映射（頁面遍歷），如果存在，則將其寫回TLB（這必須完成，因為硬體通過虛擬存儲器系統中的TLB訪問存儲器），並且重啟錯誤指令（這也可以並行發生）。此後續轉換找到TLB命中，並且內存訪問將繼續。
虛擬地址到物理地址的轉換過程，如果虛擬內存不存在與TLB，轉換會被重置並通過分頁表和硬體尋找。
通常情況下，用於處理此中斷的程序是操作系統的一部分。如果操作系統判斷此次訪問有效，那麼 操作系統會嘗試將相關的分頁從硬碟上的虛擬內存文件調入內存。 而如果訪問是不被允許的，那麼操作系統通常會結束相關的進程。
雖然叫做「頁缺失」錯誤，但實際上這並不一定是一種錯誤。而且這一機制是利用虛擬內存來增加程序可用內存空間。
發生這種情況的可能性：
當原程序再次需要該頁內的數據時，如果這一頁確實沒有被分配出去，那麼系統只需要重新為該頁在MMU內注冊映射即可。
操作系統需要：
硬性頁缺失導致的性能損失是很大的。
另外，有些操作系統會將程序的一部分延遲到需要使用的時候再載入入內存執行，以此提升性能。這一特性也是通過捕獲硬性頁缺失達到的。
當硬性頁缺失過於頻繁發生時，稱發生 系統顛簸。
具體動作與所使用的操作系統有關，比如Windows會使用異常機制向程序報告，而類Unix系統則使用信號機制。
盡管在整個運行過程中，程序引用不同的頁面總數（也就是虛擬內存大小）可能超出了物理存儲器（DRAM）總大小，但是程序常常在較小的活動頁面上活動，這個集合叫做工作集或者常駐集。在工作集被緩存後，對它的反復調用會使程序命中提高，從而提高性能。
大部分的程序都可以在存儲器獲取數據和讀取中達到穩定的狀態，當程序達到穩定狀態時，存儲器的使用量通常都不會太大。虛擬內存雖然可以有效率控制存儲器的使用， 但是大量的頁缺失還是造成了系統遲緩的主要因素。 當工作集的大小超過物理存儲器大小，程序將會發生一種不幸的情況，這種情況稱為 「顛簸」 ，頁面將不停的寫入、釋放、讀取，由於大量的丟失（而非命中）而損失極大性能。用戶可以增加隨機存取存儲器的大小或是減少同時在系統里運行程序的數量來降低系統顛簸的記錄。
推薦閱讀：
操作系統--分頁(一)
操作系統實現（二）：分頁和物理內存管理
Ⅲ 如何熟悉Linux內存管理機制
Linux內存管理機制：
一 物理內存和虛擬內存
我們知道，直接從物理內存讀寫數據要比從硬碟讀寫數據要快的多，因此，我們希望所有數據的讀取和寫入都在內存完成，而內存是有限的，這樣就引出了物理內存與虛擬內存的概念。
物理內存就是系統硬體提供的內存大小，是真正的內存，相對於物理內存，在linux下還有一個虛擬內存的概念，虛擬內存就是為了滿足物理內存的不足
Linux的內存管理採取的是分頁存取機制，為了保證物理內存能得到充分的利用，內核會在適當的時候將物理內存中不經常使用的數據塊自動交換到虛擬內存中，而將經常使用的信息保留到物理內存。
要深入了解linux內存運行機制，需要知道下面提到的幾個方面：
Linux系統會不時的進行頁面交換操作，以保持盡可能多的空閑物理內存，即使並沒有什麼事情需要內存，Linux也會交換出暫時不用的內存頁面。這可以避免等待交換所需的時間。
Linux 進行頁面交換是有條件的，不是所有頁面在不用時都交換到虛擬內存，linux內核根據」最近最經常使用「演算法，僅僅將一些不經常使用的頁面文件交換到虛擬 內存，有時我們會看到這么一個現象：linux物理內存還有很多，但是交換空間也使用了很多。其實，這並不奇怪，例如，一個佔用很大內存的進程運行時，需 要耗費很多內存資源，此時就會有一些不常用頁面文件被交換到虛擬內存中，但後來這個佔用很多內存資源的進程結束並釋放了很多內存時，剛才被交換出去的頁面 文件並不會自動的交換進物理內存，除非有這個必要，那麼此刻系統物理內存就會空閑很多，同時交換空間也在被使用，就出現了剛才所說的現象了。關於這點，不 用擔心什麼，只要知道是怎麼一回事就可以了。
交換空間的頁面在使用時會首先被交換到物理內存，如果此時沒有足夠的物理內存來容納這些頁 面，它們又會被馬上交換出去，如此以來，虛擬內存中可能沒有足夠空間來存儲這些交換頁面，最終會導致linux出現假死機、服務異常等問題，linux雖 然可以在一段時間內自行恢復，但是恢復後的系統已經基本不可用了。
因此，合理規劃和設計Linux內存的使用，是非常重要的.
二 內存的監控
作為一名Linux系統管理員，監控內存的使用狀態是非常重要的，通過監控有助於了解內存的使用狀態，比如內存佔用是否正常，內存是否緊缺等等，監控內存最常使用的命令有free、top等
Ⅳ elasticsearch使用中的問題
目前主要通過插件的形式來控制：
常用的插件主要包括：elasticsearch-http-basic，search-guard，shield
配置名 默認值 說明
http.basic.enabled true 開關，開啟會接管全部HTTP連接
http.basic.user "admin" 賬號
http.basic.password "admin_pw" 密碼
http.basic.ipwhitelist ["localhost", "127.0.0.1"] 白名單內的ip訪問不需要通過賬號和密碼，支持ip和主機名，不支持ip區間或正則
http.basic.trusted_proxy_chains [] 信任代理列表
http.basic.log false 把無授權的訪問事件添加到ES的日誌
http.basic.xforward "" 記載代理路徑的header欄位名
第二步：shutdown你要升級的節點
第三步：升級重啟該節點，並確認該節點重新加入到了集群中
第四步：重復2-3步，升級重啟其它要升級的節點。
第五步：重啟啟動集群的shard均衡
1、內存優化
在bin/elasticsearch.in.sh中進行配置
修改配置項為盡量大的內存：
ES_MIN_MEM=8g
ES_MAX_MEM=8g
兩者最好改成一樣的，否則容易引發長時間GC（stop-the-world）
elasticsearch默認使用的GC是CMS GC
如果你的內存大小超過6G，CMS是不給力的，容易出現stop-the-world
建議使用G1 GC
注釋掉：
java_OPTS=」$JAVA_OPTS -XX:+UseParNewGC」
JAVA_OPTS=」$JAVA_OPTS -XX:+UseConcMarkSweepGC」
JAVA_OPTS=」$JAVA_OPTS -XX:=75″
JAVA_OPTS=」$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly」
修改為：
JAVA_OPTS=」$JAVA_OPTS -XX:+UseG1GC」
JAVA_OPTS=」$JAVA_OPTS -XX:MaxGCPauseMillis=200″
如果G1 GC優點是減少stop-the-world在幾率，但是CPU佔有率高。
需要更優化的性能，你可以參考
http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html
2、合理配置主節點和數據節點
配置文件：conf/elasticsearch.yaml
node.master: true
node.data: true
3、設置合理的刷新時間
建立的索引，不會立馬查到，這是為什麼elasticsearch為near-real-time的原因
需要配置index.refresh_interval參數，默認是1s。
你可以像
http://zhaoyanblog.com/archives/299.html
文件中一樣，調用介面配置
也可以直接寫到conf/elasticsearch.yaml文件中
index.refresh_interval：1s
這樣所有新建的索引都使用這個刷新頻率。
小貼士1：規劃索引、分片 以及集群增長情況
ES使得創建大量索引和超大量分片非常地容易，但更重要的是理解每個索引和分片都是一筆開銷。如果擁有太多的索引或分片，單單是管理負荷就會影響到ES集群的性能，潛在地也會影響到可用性方面。這里我們專注於管理負荷，但運行大量的索引/分片依然會非常顯著地影響到索引和檢索性能。
我們發現影響管理負荷的最大因素是集群狀態數據的大小，因為它包含了集群中每個索引的所有mapping數據。我們曾經一度有單個集群擁有超過900MB的集群狀態數據。該集群雖然在運行但並不可用。
讓我們通過一些數據來了解到底發生了什麼 。。。。。。
假如有一個索引包含50k的mapping數據（我們當時是有700個欄位）。如果每小時生成一個索引，那麼每天將增加24 x 50k的集群狀態數據，或者1.2MB。如果需要在系統中保留一年的數據，那麼集群狀態數據將高達438MB（以及8670個索引，43800個分片）。如果與每天一個索引（18.25MB，365個索引，1825個分片）作比較，會看到每小時的索引策略將會是一個完全不同的境況。
幸運的是，一旦系統中有一些真實數據的話，實際上非常容易做這些預測。我們應當能夠看到集群必須處理多少狀態數據和多少索引/分片。在上到生產環境之前真的應該演練一下，以便防止凌晨3:00收到集群掛掉的電話告警。
小貼士3: 內存設置
Linux把它的物理RAM分成多個內存塊，稱之為分頁。內存交換（swapping）是這樣一個過程，它把內存分頁復制到預先設定的叫做交換區的硬碟空間上，以此釋放內存分頁。物理內存和交換區加起來的大小就是虛擬內存的可用額度。
內存交換有個缺點，跟內存比起來硬碟非常慢。內存的讀寫速度以納秒來計算，而硬碟是以毫秒來計算，所以訪問硬碟比訪問內存要慢幾萬倍。交換次數越多，進程就越慢，所以應該不惜一切代價避免內存交換的發生。
ES的mlockall屬性允許ES節點不交換內存。（注意只有Linux/Unix系統可設置。）這個屬性可以在yaml文件中設置：
bootstrap.mlockall: true
在5.x版本中，已經改成了bootstrap.memory_lock: true.
mlockall默認設置成false，即ES節點允許內存交換。一旦把這個值加到屬性文件中，需要重啟ES節點才可生效。可通過以下方式來確定該值是否設置正確：
curl http://localhost:9200/_nodes/process?pretty
如果你正在設置這個屬性，請使用-DXmx選項或ES_HEAP_SIZE屬性來確保ES節點分配了足夠的內存。
Elasticsearch默認使用服務發現(Zen discovery)作為集群節點間發現和通信的機制。Azure、EC2和GCE也有使用其他的發現機制。服務發現由discovery.zen.*開頭的一系列屬性控制。
在0.x和1.x版本中同時支持單播和多播，且默認是多播。所以要在這些版本的ES中使用單播，需要設置屬性discovery.zen.ping.multicast.enabled為false。
從2.0開始往後服務發現就僅支持單播了。
首先需要使用屬性discovery.zen.ping.unicast.hosts指定一組通信主機。方便起見，在集群中的所有主機上為該屬性設置相同的值，使用集群節點的名稱來定義主機列表。
屬性discovery.zen.minimum_master_nodes決定了有資格作為master的節點的最小數量，即一個應當「看見」集群范圍內運作的節點。如果集群中有2個以上節點，建議設置該值為大於1。一種計算方法是，假設集群中的節點數量為N，那麼該屬性應該設置為N/2+1。
初步判斷該設置可以有效防止腦裂問題
小貼士5：當心DELETE _all
必須要了解的一點是，ES的DELETE API允許用戶僅僅通過一個請求來刪除索引，支持使用通配符，甚至可以使用_all作為索引名來代表所有索引。例如:
curl -XDELETE 『 http://localhost:9200/*/ 』
這個特性非常有用，但也非常危險，特別是在生產環境中。在我們的所有集群中，已通過設置action.destructive_requires_name:true來禁用了它。
這項配置在1.0版本中開始引用，並取代了0.90版本中使用的配置屬性disable_delete_all_indices。
小貼士6：使用Doc Values
2.0及以上版本默認開啟Doc Values特性，但在更早的ES版本中必須顯式地設置。當進行大規模的排序和聚合操作時，Doc Values相比普通屬性有著明顯的優勢。本質上是將ES轉換成一個列式存儲，從而使ES的許多分析類特性在性能上遠超預期。
為了一探究竟，我們可以在ES里比較一下Doc Values和普通屬性。
當使用一個普通屬性去排序或聚合時，該屬性會被載入到屬性數據緩存中。一個屬性首次被緩存時，ES必須分配足夠大的堆空間，以便能保存每一個值，然後使用每個文檔的值逐步填充。這個過程可能會耗費一些時間，因為可能需要從磁碟讀取他們的值。一旦這個過程完成，這些數據的任何相關操作都將使用這份緩存數據，並且會很快。如果嘗試填充太多的屬性到緩存，一些屬性將被回收，隨後再次使用到這些屬性時將會強制它們重新被載入到緩存，且同樣有啟動開銷。為了更加高效，人們會想到最小化或淘汰，這意味著我們的屬性數量將受限於此種方式下的緩存大小。
相比之下，Doc Values屬性使用基於硬碟的數據結構，且能被內存映射到進程空間，因此不影響堆使用，同時提供實質上與屬性數據緩存一樣的性能。當這些屬性首次從硬碟讀取數據時仍然會有較小的啟動開銷，但這會由操作系統緩存去處理，所以只有真正需要的數據會被實際讀取。
Doc Values因此最小化了堆的使用（因為垃圾收集），並發揮了操作系統文件緩存的優勢，從而可進一步最小化磁碟讀操作的壓力。
Ⅳ linux中多級分頁的重點是什麼
"重點"是」point「的意思嗎？
使用多級頁表的point在於節省頁表本身的體積。尤其是在虛擬地址64bit的情況下，物理內存一般遠小於2^64位元組。如果用一級頁表的話，假設頁面大小4KB = 2^12B，題主自己可以算算，有2^52個頁表。而用多級頁表，就可以只有一個頂級頁表，二級三級頁表可以很「稀疏」（可以理解為「少」），這樣就大大減少了頁表個數。
Ⅵ linux分頁機制二級頁表問題
linux下的分段分頁機制將一個邏輯地址轉換到物理地址的問題？？？？？
一個邏輯地址經過分段後得到的是線性地址，我挺郁悶的這個線性地址到底如何得到的？？？應為linux的線性地址是個32位的地址，高10為保存目錄項，中間10位保存頁表項，然後低12為對應物理頁偏移地址。。。。然而這個邏輯地址是經過選擇子選出來的段基址，加上段內偏移，出來確實是個32位地址。。。似乎這個中間的步驟被屏蔽了是吧？？？我想知道這裡面是如果把邏輯地址轉換成這個分成三個部分索引的線性地址！前面是段基址然後段偏移就出來個線性地址這叫我無法接受，刨根究底！求助。。。。求助！
【分頁機制對應用程序，操作系統本身的程序都是有作用的。】
這是問題問的比較深入了，弄明白這個問題就要研究操作系統究竟怎麼分配和使用內存。
一般，不管是操作系統還是應用程序都要先分配內存然後才是內存定址和使用，而如何分配不同的系統肯定不同。操作系統種類很多，xp，2000，linux，unix。。。但一般原理還是差不多的。
以linux操作系統為例，
應用程序的內存肯定是由操作系統管的，os按分頁策略給應用程序分配內存。
那麼操作系統呢，這就是你關心的點了？
開機加電的時候linux操作系統內核代碼進入內存，一般這些內存是連續的，但這些內存在後面使用時仍能適用分頁機制去定址，不過是頁面正好是連續的罷了。
而隨著操作系統運行，內核程序也會繼續要求內存，這時候內存管理程序負責分配內存空間，這裡面有不少細節了，暫時就不啰嗦了，但無論怎麼分的，分配後使用這些內存的時候，指令地址都會以分頁機制進行定址找到分配的內存。
所以，分頁機制是整個系統的內存定址機制，對應用程序和操作系統本身都啟作用。
Ⅶ LINUX內存機制是什麼
C語言程序編寫、調試、優化都在Linux，那麼當Linux的操作系統中被C語言調用的某一個控制項的代碼文件沒了，Linux系統是能運行的但是C程序生存的"*.*"文件就不能執行了，得必須返回到C語言或反匯編中檢查調用調試系統文件情況。
比如在C++里有句dos語句"system("md
book")"，在當前目錄建立"book"文件夾，那麼就是C++調用操作系統的dos模塊命令集中"md"建文件夾的命令，那麼加入某個Linux
操作系統內有dos模塊，那這句可以運行，那麼，問題來了，有些Windows操作系統已經把dos模塊優化了，當然"system("md
book")"這句在系統里找dos的"md"命令就是空命令了。該例子與內存機制無關，當然也有有關的。
總之，C語言編寫、調試、優化需要在多種系統內驗證，否則還是存在一些移植性的問題。
Ⅷ Linux內核：分段和分頁的區別
首先說明內核的保護模式和是模式，在計算機剛剛啟動的時候處於實模式，在該模式下cpu產生20位的地址，然後計算機經過某種變換轉換到保護模式。保護模式下cpu產生32位的地址，也就是說從實模式到保護模式，cpu的定址空間擴大了。
在計算的發展的初期，intel 8086是16位的cpu，它只能運行在實模式下。在該模式下其寄存器是16位的，但是為了可以定址20位的地址空間，所以採用了內存的分段模式。
物理內存地址=段基址×16+偏移 這樣可以定址20位的地址空間。
關於現代計算機內存的分段機制，也是為了向下兼容的需要。單純的向下兼容或許還不夠有說服力，因為在現代cpu中產生的就是32的地址，而由分段機制產生的線性地址也是32位的。32位的地址完全可以訪問4G內存的任何一個地方，看上去分段機制好像完全沒有了作用，其實不然。在多線程，多任務的操作系統中，一個地址能否被一個進程寫入，能被什麼優先順序的進程訪問，是否允許執行這些問題有出來了。而解決這些問題需要在地址上添加一些屬性，也就是說其地址應該還是高於32位的。這時候有體現了分段機制的作用。
關於分頁機制。由分頁機制產生線性地址，加入沒有分頁，這個線性地址就是物理地址。而分頁機制就是把線性地址裝換成物理地址。關於其原因，一方面在進程產生子進程的時候，會復制內存頁，而父子進程無論是代碼數據還是產生的地址都是一樣的，這樣為創建進程提供了便利，可以不必考慮進程在內存中分布的情況而產生地址，至於父子進程的真實物理地址在哪裡，那是mmu（內存控制單元）的問題。另一方面，由於進程不知道真實的物理地址子啊什麼地方，也為操作系統提高了安全性。
Ⅸ linux內存分頁分段地址轉換由什麼實現
分頁所完全是系統實現，咱們看不到，分段是用戶程序決定到，分頁中用到了頁表和快表，！
Ⅹ linux內核態是實模式還是分頁模式
linux運行在保護模式下，並且在啟動保護模式之前准備好了分頁式內存管理的頁表，在進入保護模式的同時一並開啟了分頁模式（同時置PE和PG位，即or eax,0x80000001）。
需要注意的是不要把保護模式和分頁模式混淆，與實模式相對的是保護模式，與分頁式內存管理相對的是分段式內存管理；當然，也有兩者結合的段頁式。