[内存管理] linux kernel内存映射实例分析

作者：JHJ(jianghuijun211@gmail.com)
日期：2012/08/24

欢迎转载，请注明出处

 

引子

现在android智能手机市场异常火热，硬件升级非常迅猛，arm cortex A9 + 1GB DDR似乎已经跟不上主流配置了。虽说硬件是王道，可我们还是不禁还怀疑这么强大的硬件配置得到充分利用了吗？因此以后我都会正对ARM平台分析kernel的内容。 

正文

在linux内存管理中，有两个资源非常重要，一个是虚拟地址，一个是物理地址。听起来似乎是废话，实际上内存管理主要就是围绕这两个概念展开的。如果对linux kernel如果管理虚拟地址和物理地址还没有概念的，建议浏览一下文献【2】，这是一本很棒的书，言简意赅。文献【1】会讲更多的实现细节。

本文主要目的是对内核1GB虚拟地址空间映射有个总体了解，包括：

1. 1GB内核虚拟地址空间具体用于什么地方？

2. 其和实际物理地址的映射关系.

3. 一些板级相关的宏定义，为了便于日后查阅，我也将这些宏定义整理了出来。根据这些宏定义，你也可以轻松画出你所用的平台的内核虚拟地址空间映射关系。

首先申明，实例中的映射规划不见得就是最优的，但它却是一个实际的例子。实际上我个人觉得还是有很多值得商榷的地方。

从下图我们可以看到，粉色部分0xbf80 0000 ~ 0xc000 0000是为modules及kpmap的，从下面的板级宏定义我们可以看到，modules放在这段位置是因为它需要和kernel code段在32MB寻址空间内。kpmap为什么放这段空间我还不清楚，这个是在map highmem时用到的。

橙色部分0xc000 0000 ~ 0xe000 0000映射 lowmem(低端内存，即zone[Normal])。这段映射是一对一的平坦映射，也就是说kernel初始化这段映射后，页表将不会改变。这样即可以省去不断的修改页表，刷新TLB（TLB可以认为是页表的硬件cache，如果访问的虚拟地址的页表在这个cache中，则CPU无需访问DDR寻址页表了，这样可以提高IO效率）了。显然这段地址空间非常珍贵，因为这段映射的效率高。从图中我们可以看到，在512MB映射空间中，有128MB预留给PMEM（android特有的连续物理内存管理机制），16MB预留CP（modem运行空间）。实际可用lowmem大致只有360MB。

蓝色部分0xe000 0000 ~ 0xf000 0000银蛇highmem（高端内存，即zone[HighMem]）。因为示例为1GB DDR，因此需要高端内存映射部分物理地址空间。

绿色部分0xf000 0000 ~ 0xffc0 0000为IO映射区域。我们知道在内核空间，比如写驱动的时候，需要访问芯片的寄存器（IO空间），部分IO空间映射是通过ioremap在VMALLOC区域动态申请映射，还有部分是系统初始化时通过iotable_init静态映射的。图中我们可以看到在IO静态映射区域有大约200MB的空间没有使用。这个是不是太浪费了呢？

紫色部分没什么花头，ARM default定义就是这样的。

下图给出了内核虚拟地址空间和实际物理地址的映射关系。

 

下面开始玩点激情的，看看这个mapping存在什么问题。

实际上我在这个平台上遇到一个bug，即在用monkey test做压力测试的时候，系统运行很长时间后会出现vmalloc失败。OMG，调用vmalloc都会失败，而且此时还有足够多的物理内存，神奇吧？

【错误log】系统的graphic模块在用vmalloc申请1MB内存时失败

【分析】

1. 首先查看此时基本的内存信息。通过/proc/meminfo可以看到，实际可用物理内存还剩156MB，内存此时并未耗尽。vmalloc所使用的VMALLOC虚拟地址还剩余22MB，也是够用的。根据vmalloc实现原理，它会通过调用alloc_page()去buddy系统中取一个个孤立的page（即在2^0链表上取page）。page此时是足够多的，为什么会申请失败呢？vmalloc要求虚拟地址是连续的&