Linux核心記憶體管理報價
我在理解 Linux 設備驅動程序書中的這段摘錄時遇到了令人難以置信的困難（對不起，對於文字繁重的文章）：
核心（在 x86 架構上，在預設配置中）在使用者空間和核心之間分割了 4 GB 的虛擬地址空間；在兩種情況下都使用相同的映射集。典型的拆分將 3 GB 用於使用者空間，1 GB 用於核心空間。
好的，我知道了。
核心的程式碼和資料結構必須適合該空間，但核心地址空間的最大消耗者是物理記憶體的虛擬映射。
這是什麼意思？核心的程式碼和資料結構不是也在“映射到物理地址空間的虛擬記憶體”中嗎？否則這些程式碼和資料結構甚至儲存在哪裡？
或者這是說核心需要虛擬地址空間來映射它通過驅動程序、IPC 或其他方式執行的隨機非核心相關數據？
核心不能直接操作未映射到核心地址空間的記憶體。換句話說，核心需要它自己的虛擬地址來存放它必須直接接觸的任何記憶體。
這是真的嗎？如果核心在程序上下文中執行（處理系統呼叫），程序的頁表仍然會被載入，那麼為什麼核心不能直接讀取使用者態程序記憶體呢？
因此，多年來，核心可以處理的最大物理記憶體量是可以映射到核心虛擬地址空間部分的數量，減去核心程式碼本身所需的空間。
好的，如果我對引用 #2 的理解是正確的，這是有道理的。
因此，基於 x86 的 Linux 系統最多可以使用略低於 1 GB 的物理記憶體。
？？？這似乎完全不合邏輯。為什麼它不能使用 4GB 記憶體，而只是根據需要將不同的東西映射到核心可用的 1GB 空間中？核心空間只有 ~1GB 意味著系統無法以 4GB 執行？它不必一次全部映射。
為什麼它不能使用 4GB 記憶體，而只是根據需要將不同的東西映射到核心可用的 1GB 空間中？
它可以，這就是
HIGHMEM配置選項對不適合直接映射的記憶體所做的事情。但是當您需要訪問記憶體中的任意位置時，如果您可以直接指向它，那麼這樣做會容易得多，而無需每次都設置映射。為此，您需要一個始終映射到所有物理記憶體的虛擬記憶體區域，如果虛擬地址空間小於物理地址空間，則無法做到這一點。直接訪問也更快，
vm/highmem.txt在核心文件中說：創建臨時映射的成本可能非常高。Arch 必須操作核心的頁表、數據 TLB 和/或 MMU 的寄存器。
當然，您可以通過使用者空間映射來訪問正在執行的程序的記憶體，也許您可以避免訪問其他程序的記憶體。但是如果有任何大的核心資料結構（如頁面記憶體），能夠為它們使用所有記憶體會很好。
整個事情是一種銀行切換，這是用於 16 位機器和 DOS 時代 ( HIMEM.SYS ) 的 386/486 系統中的東西。我認為即使在那時也沒有人特別喜歡像那樣訪問記憶體，因為如果您需要同時“打開”物理記憶體的多個區域，這會使事情變得相當困難。發展到 32 位，然後發展到 64 位系統已經解決了這個問題。