Linux用户进程内存分配及二级页表PTE的二三事
Linux用户进程内存分配及二级页表PTE的二三事
我们在用调试器看Linux用户进程代码时，发现了一件很有意思的事情，在一段内存空间中，有一整页（4K）都是data abort，如下：
第一页4011c000数据正常
... ...
4011cfec [0xe28dd014] add r13,r13,#0x14
4011cff0 [0xe8bd40f0] ldmfd r13!,{r4-r7,r14}
4011cff4 [0xe12fff1e] bx r14
4011cff8 [0xe92d41f0] stmfd r13!,{r4-r8,r14}
4011cffc [0xe59f4064] ldr r4,0x4011d068
第二页4011d000 都是Data abort
4011d000 *** Data abort ***
4011d004 *** Data abort ***
4011d008 *** Data abort ***
4011d00c *** Data abort ***
... ...
第三页 4011e000 数据正常
4011e000 数据正常
由于当时并不知道Linux是如何处理用户进程的内存分配，所以认为这是一个“错误”。既然有错误，我们决定找到这个问题发生的根源。
在追踪这个问题的过程中，leeming同学做了一个很BT的实验。我简单说两句，详细大家可以去看他的文章（ http://blog.chinaunix.net/u3/99423/showart_2096904.html）。大概的方法就是将物理内存全部dump出来，通过第一页的代码，比如0xe59f4064，查找其在内存中的物理地址，再通过提取物理地址的前20位，就可以查找Linux系统的二级页表（对应ARM的TLB，Linux中叫PTE）。这个实验虽然看上去很不可思议，但实现起来并不复杂。最终得到了Linux存放在内存中的TLB数据。
每个表项是32bit
虚拟页地址 对应表项的内容
4011c000 3156caae
4011d000 00000000
4011e000 3156faae
很有意思，Data abort的数据段，对应的PTE也是空的，这难道是一个系统错误？
NO！经过进一步的学习后发现，在Linux系统中，这是一个很正常的现象。Linux在用户进程执行时并没有建立所有内存页面的映射，而是需要用到的时候再建立映射关系。当Linux用户进程访问到没有建立映射的页表（此时PTE指针为0），会调用相应的函数进行处理，或建立、或换出，具体执行这个操作的函数叫handle_pte_fault（），位于内核的mm/memory.c中。
但是，Linux是如何进入缺页处理的呢？
有两种情况，都是利用了ARM处理器的异常中断进行相应的处理。
第一种是程序顺序执行，正常页面的最后一条指令执行完后进入空页面，当空页面的第一条指令进入ARM处理器流水线的执行周期时，ARM处理器会报告一个指令预取异常中断，并跳转到地址0x0c，在Linux系统中由于使用了高地址向量表，所以会跳转到0xffff000c。此时ARM处理器进入ABORT状态，执行一系列代码保存现场（代码位于/arch/arm/kernel/entry-armv.s），然后进入SVC状态执行arch/arm/mm/fault.c中的do_PrefetchAbort（），最后会调用handle_pte_fault（）处理缺页异常。
第二种情况，页面中的程序执行时需要使用未分配页面的数据，比如“ldr r0,未分配页地址”。遇到这种情况，就不是指令预取异常了，而是数据访问异常（Data abort）。此时处理器依然会进入ABORT状态，跳转到0xffff0010执行相应的vector_dabt代码（entry_armv.s）保存状态，进入SVC态，执行do_DataAbort（）函数，最后同样调用handle_pte_fault（）处理缺页异常。
因此，最开始遇到的情况：三个PTE，中间是空的，这是一个很正常的情况。因为第三页很可能由于前面的调用而已经建立，第二页却还没有建立。
至于handle_pte_fault（）如何处理缺页异常，我还没有看完，就不在本文讨论了。已知至少有do_no_page()、do_swap_page()、do_wp_page等多种方式，此为后话。
通过跟踪用户程序，发现Linux用户进程基本所有的页面都是这样处理，因此处理器会很频繁的进出Abort状态，执行页面处理函数，这是会不会效率有点低了呢？待研究。
handle_pte_fault（）
上文最后提到了handle_pte_fault（）这个函数，用来处理页错，分配PTE。为了更清楚的了解PTE是如何申请到的，还是有必要深究一下。
handle_pte_fault（）有几个函数用来检查当前pte的状态：
pte_present（） 检测页面是否在内存中
pte_none（） 检测页表项是否为空
pte_file（） 同一地址多映射（此函数不重要）
vm->ops->fault标记位
内核用likely对其做了标记，说明这个标记一般满足，适用于已经建立好虚拟内存和文件的映射关系的情况。
1）针对满足pte_present（）函数，即PTE不在内存中，会在以4个下函数中选择一个进行处理：
（1）do_linear_fault（）；
最常见的情况，PTE表项为空，但满足vm->ops->fault，说明已经在内存中建立虚拟内存和文件的映射关系。
（2）do_anonymous_page（）；
PTE表项为空，但是没有建立和文件的映射关系，说明是第一次demanding page。
（3）do_nonlinear_fault（）；
PTE表项非空，满足pte_file（）检查，对同一个物理地址做多个虚拟映射。
（4）do_swap_page（）；
PTE表项非空，不满足pte_file（）检查，此页将会被换出。
2）如果不满足pte_present（），即PTE在内存中，则会执行下面的COW操作：
COW的全称叫做“copy on write”，即写时复制。这一块是涉及到两个进程共享操作的，简单的说两个进程可以共享页面（特别是fork出的进程），只有当一个进程需要写入文件时，才从同一页面复制一份副本。下面的函数调用do_wp_page（），将生成的复制页赋值给写进程。由于我仅仅跟了系统的“/sbin/init”，所以这里根本没有调用到。
附：
do_anonymous_page（）函数的跟踪
——>mk_pte（） 构建映射表
——>ptn_pte（）
——>__pte（（ptn << 12 | pgprot_val）
最终生成的PTE为32bit，其中20bit物理地址，12bit控制信息
第一页4011c000数据正常
... ...
4011cfec [0xe28dd014] add r13,r13,#0x14
4011cff0 [0xe8bd40f0] ldmfd r13!,{r4-r7,r14}
4011cff4 [0xe12fff1e] bx r14
4011cff8 [0xe92d41f0] stmfd r13!,{r4-r8,r14}
4011cffc [0xe59f4064] ldr r4,0x4011d068
第二页4011d000 都是Data abort
4011d000 *** Data abort ***
4011d004 *** Data abort ***
4011d008 *** Data abort ***
4011d00c *** Data abort ***
... ...
第三页 4011e000 数据正常
4011e000 数据正常
由于当时并不知道Linux是如何处理用户进程的内存分配，所以认为这是一个“错误”。既然有错误，我们决定找到这个问题发生的根源。
在追踪这个问题的过程中，leeming同学做了一个很BT的实验。我简单说两句，详细大家可以去看他的文章（ http://blog.chinaunix.net/u3/99423/showart_2096904.html）。大概的方法就是将物理内存全部dump出来，通过第一页的代码，比如0xe59f4064，查找其在内存中的物理地址，再通过提取物理地址的前20位，就可以查找Linux系统的二级页表（对应ARM的TLB，Linux中叫PTE）。这个实验虽然看上去很不可思议，但实现起来并不复杂。最终得到了Linux存放在内存中的TLB数据。
每个表项是32bit
虚拟页地址 对应表项的内容
4011c000 3156caae
4011d000 00000000
4011e000 3156faae
很有意思，Data abort的数据段，对应的PTE也是空的，这难道是一个系统错误？
NO！经过进一步的学习后发现，在Linux系统中，这是一个很正常的现象。Linux在用户进程执行时并没有建立所有内存页面的映射，而是需要用到的时候再建立映射关系。当Linux用户进程访问到没有建立映射的页表（此时PTE指针为0），会调用相应的函数进行处理，或建立、或换出，具体执行这个操作的函数叫handle_pte_fault（），位于内核的mm/memory.c中。
但是，Linux是如何进入缺页处理的呢？
有两种情况，都是利用了ARM处理器的异常中断进行相应的处理。
第一种是程序顺序执行，正常页面的最后一条指令执行完后进入空页面，当空页面的第一条指令进入ARM处理器流水线的执行周期时，ARM处理器会报告一个指令预取异常中断，并跳转到地址0x0c，在Linux系统中由于使用了高地址向量表，所以会跳转到0xffff000c。此时ARM处理器进入ABORT状态，执行一系列代码保存现场（代码位于/arch/arm/kernel/entry-armv.s），然后进入SVC状态执行arch/arm/mm/fault.c中的do_PrefetchAbort（），最后会调用handle_pte_fault（）处理缺页异常。
第二种情况，页面中的程序执行时需要使用未分配页面的数据，比如“ldr r0,未分配页地址”。遇到这种情况，就不是指令预取异常了，而是数据访问异常（Data abort）。此时处理器依然会进入ABORT状态，跳转到0xffff0010执行相应的vector_dabt代码（entry_armv.s）保存状态，进入SVC态，执行do_DataAbort（）函数，最后同样调用handle_pte_fault（）处理缺页异常。
因此，最开始遇到的情况：三个PTE，中间是空的，这是一个很正常的情况。因为第三页很可能由于前面的调用而已经建立，第二页却还没有建立。
至于handle_pte_fault（）如何处理缺页异常，我还没有看完，就不在本文讨论了。已知至少有do_no_page()、do_swap_page()、do_wp_page等多种方式，此为后话。
通过跟踪用户程序，发现Linux用户进程基本所有的页面都是这样处理，因此处理器会很频繁的进出Abort状态，执行页面处理函数，这是会不会效率有点低了呢？待研究。
handle_pte_fault（）
上文最后提到了handle_pte_fault（）这个函数，用来处理页错，分配PTE。为了更清楚的了解PTE是如何申请到的，还是有必要深究一下。
handle_pte_fault（）有几个函数用来检查当前pte的状态：
pte_present（） 检测页面是否在内存中
pte_none（） 检测页表项是否为空
pte_file（） 同一地址多映射（此函数不重要）
vm->ops->fault标记位
内核用likely对其做了标记，说明这个标记一般满足，适用于已经建立好虚拟内存和文件的映射关系的情况。
1）针对满足pte_present（）函数，即PTE不在内存中，会在以4个下函数中选择一个进行处理：
（1）do_linear_fault（）；
最常见的情况，PTE表项为空，但满足vm->ops->fault，说明已经在内存中建立虚拟内存和文件的映射关系。
（2）do_anonymous_page（）；
PTE表项为空，但是没有建立和文件的映射关系，说明是第一次demanding page。
（3）do_nonlinear_fault（）；
PTE表项非空，满足pte_file（）检查，对同一个物理地址做多个虚拟映射。
（4）do_swap_page（）；
PTE表项非空，不满足pte_file（）检查，此页将会被换出。
2）如果不满足pte_present（），即PTE在内存中，则会执行下面的COW操作：
COW的全称叫做“copy on write”，即写时复制。这一块是涉及到两个进程共享操作的，简单的说两个进程可以共享页面（特别是fork出的进程），只有当一个进程需要写入文件时，才从同一页面复制一份副本。下面的函数调用do_wp_page（），将生成的复制页赋值给写进程。由于我仅仅跟了系统的“/sbin/init”，所以这里根本没有调用到。
附：
do_anonymous_page（）函数的跟踪
——>mk_pte（） 构建映射表
——>ptn_pte（）
——>__pte（（ptn << 12 | pgprot_val）
最终生成的PTE为32bit，其中20bit物理地址，12bit控制信息