# Day 16 Physical Memory Model(一)

从前几篇文章可以看得出来，笔者对於 kernel mm subsystem 其实很不熟悉啊！
决定调整一下整个系列的规划，在简介规划时，接下来要读的是 cgroup 相关的文件；但看起来，kernel 中像是 mm、中断相关这些更为基础的 infrastructure 知之都不甚详，所以接下来还是先针对记忆体管理相关的文件好好的阅读；
接下来，会来阅读 Linux Memory Management Documentation 这里面的文件并做纪录，而笔者对於开机过程中，实体记忆体是如何被记录和操作，分页表是如何建立的尤有兴趣，希望有机会能在这些文件找到一些蛛丝马迹，再搭配 RTFSC 大法，做一个完整的纪录。

事不宜迟，今天就从 Physical Memory Model 开始吧！

文件

• 文件原文：Physical Memory Model
• 翻译：

.. SPDX-License-Identifier: GPL-2.0

.. _physical_memory_model:

=============
实体记忆体模型
=============

系统中的实体记忆体可以用不同的方式定址。
最简单的情况是实体记忆体从位址 0 开始并延续一个连续的范围直到最大位址。 
然而，这范围可能包含 CPU 无法存取的记忆体"孔洞"；并且有可能存在不同的连续范围在不同的位址。
还有别忘记 NUMA，其中不同的记忆体组连接到不同的 CPU 上。

Linux 使用两种记忆体模型来抽像这种多样性：FLATMEM 和 SPARSEMEM。
每个架构都定义了它支援的记忆体模型、预设的记忆体模型是什麽以及是否可以手动覆盖该预设值。

所有记忆体模型都使用一个或多个阵列中的 struct page 来纪录实体页框的状态。

无论选择哪种记忆体模型，实体页框号码（PFN）和相应的 struct page 之间都存在一对一的映射关系。

每个记忆体模型都定义了 :c:func:`pfn_to_page` 和 :c:func:`page_to_pfn`，
这两个 helper 实作了 PFN 以及 struct page 之间的转换。

FLATMEM
=======

最简单的记忆体模型是 FLATMEM。该模型适用於具有连续，
或大部分连续实体记忆体的非 NUMA 系统。

在 FLATMEM 记忆体模型中，有一个全域的 `mem_map` 阵列映射了整个实体记忆体。
对於大多数架构，"记忆体孔洞" 是会占用 `mem_map` 阵列中元素；
而若 `struct page` 物件对应的是"记忆体孔洞"，则该物件不会被完全的初始化。

要分配记忆体给 `mem_map` 阵列，架构相关的设置程序码应该使用 :c:func:`free_area_init` 函数。
然而，直到呼叫 :c:func:`memblock_free_all` 来将所有记忆体转交给分页分配器(page allocator)之前，
这个映射阵列(mapping array) 是不可以使用的。

某些架构可能会释放某部分并未对应到实际实体记忆体分页的 `mem_map` 阵列，
在这种情况下，架构相关的 :c:func:`pfn_valid` 实做需要将在 `mem_map` 中的记忆体孔洞考虑在内。

在 FLATMEM 中，PFN 和 `struct page` 之间的转换是非常直觉的：
`PFN - ARCH_PFN_OFFSET` 是 `mem_map` 阵列的索引 (index)。

`ARCH_PFN_OFFSET` 定义了实体记忆体的起始位址不为 0 系统的第一个页框编号。

我的理解

• Linux 下的实体记忆体模型分两种：FLATMEM、SPARSEMEM
  • 从名字感觉起来，FLATMEM 就是一般记忆体的感觉；而 SPARSEMEM 感觉上像是记忆体上有很多的"孔洞" (无法存取或是留给其他装置的记忆体区段)，不过这边我们等文件都看完了再来详细记录
• Linux 下都是用 struct page 来记录实体记忆体分页，而一般分页大小是 4KB
• struct page 和实体记忆体分页编号 (PFN) 可以透过 pfn_to_page、page_to_pfn 来做转换

後记

今天先翻译了这篇文件的前三分之一，文件本身的说明都满直观、简洁的，有一些基础的 paging 概念就能大致上稍微理解目前看到的文件内容，至於文件中提到的 API 细节，我们就留待後续揭晓罗！
感谢各位，我们明天见！