随着硬件能力的提升,系统内存容量变得越来越大。尤其是在服务器上,过T级别的内存容量也已经不罕见了。
如此海量内存给内核带来了很多挑战,其中之一就是page struct存放在哪里。
page struct的三种存放方式
在内核中,我们将物理内存按照页大小进行管理。这样每个页就对应一个page struct作为这个页的管理数据结构。
随着内存容量的增加,相对应的page struct也就增加。而这部分内存和其他的内存略有不同,因为这部分内存不能给到页分配器。也就是必须在系统能够正常运行起来之前就分配好。
在内核中我们可以看到,为了应对这样的变化进化出了几个不同的版本。有幸的是,这部分内容我们现在还能在代码中直接看到,因为这个实现是通过内核配置来区分的。我们通过查找_pfn_to_page的定义就能发现一下几种memory model:
CONFIG_FLATMEM
CONFIG_SPARSEMEM
CONFIGSPARSEMEMVMEMMAP
接下来让小编给各位看官一一道来。
1) FLATMEM
在这种情况下,宏_pfn_to_page的定义是:
#define __pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET))
而这个mem_map的定义是
struct page *mem_map;
所以在这种情况下,page struct就是一个大数组,所有的人都按照自己的物理地址有序得挨着。
2) SPARSEMEM
虽然第一种方式非常简单直观,但是有几个非常大的缺点:
内存如果有空洞,那么中间可能会有巨大的page struct空间浪费
所有的page struct内存都在一个NUMA节点上,会耗尽某一个节点内存,甚至是分配失败
且会产生夸NUMA访问导致性能下降
所以第二种方式就是将内存按照一定粒度,如128M,划分了p,每个p中有个成员指定了对应的page struct的存储空间。
这样就解决了上述的几个问题:
如果有空洞,那么对应的 page struct就不会占用空间
每个p对应的page struct是属于本地NUMA的
怎么样,是不是觉得很完美。这一部分具体的实现可以可以看函数sparse_init()函数。
有了这个基础知识,我们再来看这种情况下_pfn_to_page的定义:
#define __pfn_to_page(pfn) \
({ unsigned long __pfn = (pfn); \
struct mem_p *__sec = __pfn_to_p(__pfn); \
__p_mem_map_addr(__sec) + __pfn; \
})
就是先找到pfn对应的p,然后在p中保存的地址上翻译出对应pfn的page struct。
既然讲到了这里,我们就要对sparsemem中重要的组成部分mem_p多说两句。
先来一张mem_p的整体图解:
这是一个 NRSECTIONROOTS x SECTIONSPERROOT的二维数组。其中每一个成员就代表了我们刚才提到的128M内存。
当然最开始它不是这个样子的。
其实最开始这个数组是一个静态数组。很明显这么做带来的问题是这个数组定义太大太小都不合适。所以后来引进了CONFIGSPARSEMEMEXTREME编译选项,当设置为y时,这个数组就变成了动态的。
如果上面这个算作是空间上的限制的话,那么接下来就是一个时间上的限制了。
在系统初始化时,每个mem_p都要和相应的内存空间关联。在老版本上,这个步骤通过对整个数组接待完成。原来的版本上问题不大,因为整个数组的大小还没有很大。但随着内存容量的增加,这个数值就变得对系统有影响了。如果系统上确实有这么多内存,那么确实需要初始化也就忍了。但是在内存较小的系统上,哪怕没有这么多内存,还是要挨个初始化,那就浪费了太多的时间。
commit c4e1be9ec1130fff4d691cdc0e0f9d666009f9ae
Author: Dave Hansen <dave.hansen@linux.intel.com>
Date: Thu Jul 6 15:36:44 2017 -0700
mm, sparsemem: break out of loops earl
Dave在这个提交中增加了对系统最大存在内存的跟踪,来减少不必要的初始化时间。
瞧,内核代码一开始其实也没有这么高大上不是。
3) SPARSEMEM_VMEMMAP
最后要讲的,也是当前x86系统默认配置的内存模型是SPARSEMEM_VMEMMAP。那为什么要引入这么一个新的模型呢?那自然是sparsemem依然有不足。
细心的朋友可能已经注意到了,前两种内存模型在做pfn到page struct转换是有着一些些的差异。为了看得清,我们把这两个定义再拿过来对比一下:
先看看FLATMEM时的定义:
#define __pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET))
再来看看使用SPASEMEM后的定义:
#define __pfn_to_page(pfn) \
({ unsigned long __pfn = (pfn); \
struct mem_p *__sec = __pfn_to_p(__pfn); \
__p_mem_map_addr(__sec) + __pfn; \
})
更改后,需要先找到p,然后再从p->memmap的内容中换算出page的地址。
不仅计算的内容多了,更重要的是还有一次访问内存的操作
可以想象,访问内存和单纯计算之间的速度差异那是巨大的差距。
既然产生了这样的问题,那有没有办法解决呢?其实说来简单,内核开发者利用了我们常见的一个内存单元来解决这个问题。
页表
是不是很简单粗暴?如果我们能够通过某种方式将page struct线性映射到页表,这样我们不就能又通过简单的计算来换算物理地址和page struct了么?
内核开发者就是这么做的,我们先来看一眼最后那简洁的代码:
#define __pfn_to_page(pfn) (vmemmap + (pfn))
经过内核开发这的努力,物理地址到page struct的转换又变成如此的简洁。不需要访问内存,所以速度的问题得到了解决。
但是天下没有免费的午餐,世界哪有这么美好,鱼和熊掌可以兼得的情况或许只有在梦境之中。为了达到如此简洁的转化,我们是要付出代价的。为了实现速度上的提升,我们付出了空间的代价。
至此引出了计算机界一个经典的话题:
时间和空间的转换
话不多说,也不矫情了,我们来看看内核中实现的流程。
既然是利用了页表进行转换,那么自然是要构建页表在做这样的映射。这个步骤主要由函数vmemmap_populate()来完成,其中还区分了有没有大页的情况。我们以普通页的映射为例,看看这个实现。
int __meminit vmemmap_populate_basepages(unsigned long start,
unsigned long end, int node)
{
unsigned long addr = start;
pgd_t *pgd;
p4d_t *p4d;
pud_t *pud;
pmd_t *pmd;
pte_t *pte;
for (; addr < end; addr += PAGE_SIZE) {
pgd = vmemmap_pgd_populate(addr, node);
if (!pgd)
return -ENOMEM;
p4d = vmemmap_p4d_populate(pgd, addr, node);
if (!p4d)
return -ENOMEM;
pud = vmemmap_pud_populate(p4d, addr, node);
if (!pud)
return -ENOMEM;
pmd = vmemmap_pmd_populate(pud, addr, node);
if (!pmd)
return -ENOMEM;
pte = vmemmap_pte_populate(pmd, addr, node);
if (!pte)
return -ENOMEM;
vmemmap_verify(pte, node, addr, addr + PAGE_SIZE);
}
return 0;
}
内核代码的优美之处就在于,你可能不一定看懂了所有细节,但是从优美的结构上能猜到究竟做了些什么。上面这段代码的工作就是对每一个页,按照层级去填充页表内容。其中具体的细节就不在这里展开了,相信有兴趣的同学会自行去探索。
那这么做的代价究竟是多少呢?
以x86为例,每个p是128M,那么每个p的page struct正好是2M,也就是一个大页。
(128M / 4K) * 64 = (128 * (1 < 20) / (1 < 12)) * 64 = 2M
假如使用大页做页表映射,那么每64G才用掉一个4K页表做映射。
128M * 512 = 64G
所以在使用大页映射的情况下,这个损耗的级别在百万分之一。还是能够容忍的。
好了,我们终于沿着内核发展的历史重走了一遍安放page struct之路。相信大家在这一路上领略了代码演进的乐趣,也会对以后自己代码的设计有了更深的思考。
(END)
更多精彩,尽在"Linux阅码场",扫描下方二维码关注
别忘了点个赞和在看哦
来源:oschina
链接:https://my.oschina.net/u/4415802/blog/4376468