Memory Linux Kernel 中的映射 - 使用 vamlloc() 和 kmalloc()

Question

Considering a 32bit x86 Linux system with 4 GB of RAM memory, So as described in books as well as on many forums that the Memory mapping would be as follows:

1. Kernel 邏輯地址- 最多896 MB - 一對一映射，可以使用kmalloc()分配。
2. Kernel 虛擬地址- 128MB （896MB 以上 - kernel 邏輯地址） - 使用vmalloc()分配並分配虛擬連續但物理上（分散在RAM內）非連續 kernel 頁面

我無法完全理解並需要澄清的幾點。

1. 我的理解是，當使用kmalloc()分配memory 時，它總是來自RAM 中的0 到896MB，而不是超出這個范圍。

2. 當我們使用vmalloc()分配 memory 時，memory 是否在 RAM 中分配了 896MB 到 4GB 范圍內的任何地方？ 還是僅在 RAM 內從 896MB 到 1GB 范圍內分配？

3. 當我們說 kernel 只有 1GB 的虛擬地址空間時，那是否意味着 kernel 無法訪問超過 1GB 的 RAM？ 如果可以，那么它是如何完成的？ kernel 的 128MB 虛擬地址空間是否用於此目的？

請幫忙。

Answer 1

理論上有 3 種不同的“內存管理器”。 一個管理物理 RAM（主要跟蹤空閑物理 RAM 的頁面），一個管理虛擬空間（映射到每個虛擬地址空間的內容，使用固定大小的片段 - 頁面大小），第三個管理“堆”（允許將更大區域的虛擬地址空間分成任意大小的塊）。

起初; Linux kernel 試圖使用它的 kernel “堆”來管理所有這三個非常不同的東西。 通過將“所有 RAM”線性映射到 kernel 空間，它們繞過了管理內核虛擬 memory 的需要，最終在 kernel 空間中的虛擬地址和物理地址之間建立了簡單的關系“堆”您還分配物理 memory。

最初這很好，因為當時計算機很少有超過 128 MiB 的 RAM（Linus 並不期望 kernel 存在很長時間，因為 GNU 計划“很快”切換到 Hurd），並且 kernel 空間顯着大於“所有 RAM”。 隨着 RAM 數量的增加，它變成了一個問題——“所有 RAM”變得比 kernel 空間大，所以“使用堆來管理 3 個非常不同的東西”是行不通的。

當然，一旦出現問題，很多內核代碼都依賴於“kmalloc 分配物理內存”，因此很難解決問題。 相反，他們將物理 memory 拆分為 2 個區域 - 一個由“kmalloc”管理的區域和另一個由“vmalloc”管理的區域； 然后更改 kernel 的部分以使用“vmalloc”而不是“kmalloc”，這樣很容易進行這些更改。

1. 我的理解是，當使用kmalloc() 分配memory 時，它總是來自RAM 中的0 到896MB，而不是超出這個范圍。

是的; 這是物理 memory 的第一個區域，它適合“kmalloc”使用的 kernel 空間映射。

2. 當我們使用 vmalloc() 分配 memory 時，memory 是否在 RAM 中分配了 896MB 到 4GB 范圍內的任何地方？ 還是僅在 RAM 內從 896MB 到 1GB 范圍內分配？

它將從不在第一個區域（“896MB 或更高”范圍內的任何位置）中的任何 RAM 分配。

3. 當我們說 kernel 只有 1GB 的虛擬地址空間時，那是否意味着 kernel 無法訪問超過 1GB 的 RAM？ 如果可以，那么它是如何完成的？ kernel 的 128MB 虛擬地址空間是否用於此目的？

內核的 1 GiB 虛擬空間； 一些 (896MB) 將是物理地址空間的線性映射，一些將是 memory 映射 (PCI) 設備，還有一些將被留作可以進行動態映射的區域。 對於“vmalloc”，kernel 將分配 RAM 的物理頁面，然后將 map 分配到“動態映射區域”（並返回一個指向與其物理地址無關的映射位置的指針，並打破“物理 = 虛擬 -基”關系）。

注 1：確切的大小/限制是可變的 - 例如 kernel 可以編譯為“2 GiB / 2 GiB 拆分”，其中 kernel 空間為 2 GiB（而不是“3 GiB / 1 GiB 拆分”）； 並且“kmalloc 區域”的大小可能取決於各種因素（PCI 設備需要多少空間、有多少 RAM 等），並且可能不是 896MB。

注2：由於引入了“vmalloc”來解決原來的問題； 計算機切換到 64 位（其中“所有內存”可以/確實適合 kernel 空間），並且“vmalloc”變得不必要（並且可能只是落入“kmalloc”）。 然而，許多其他變化已經發生（NUMA 的引入、加密 RAM、非易失性 RAM ......；加上任何一個人都無法追蹤的更多安全漏洞），因此最初的設計缺陷已經達到了暫時的“壞主意，但如果我們繼續為安全漏洞添加變通方法，技術上仍然不會損壞”階段（直到 RAM 和非易失性 RAM 的大小不可避免地增加，並且在未來的某個時候再次需要“vmalloc” - 可能在大約 30 年內）。