Linux 内存管理系统：初始化

「爱情、让人受尽委屈。」 2022-08-14 01:46 294阅读 0赞

作者：Joe Knapka  
臭翻：colyli  
内存管理系统的初始化处理流程分为三个基本阶段：  
激活页内存管理  
 在swapper\_pg\_dir中初始化内核的页表  
 初始化一系列和内存管理相关的内核数据  
 Turning On Paging (i386)  
启动分页机制(i386)  
Kernel 代码被加载到物理地址0x100000(1MB)，在分页机制打开后被重新映射到  
PAGE\_OFFSET + 0x100000的位置（PAGE\_OFFSET在IA32上为3GB，即进程虚拟地址中用户  
空间与内核空间的分界处）。这是通过将物理地址映射到编译进来的页表 (在  
arch/i386/kernel/head.S中)的0－8MB以及PAGE\_OFFSET－PAGE\_OFFSET+8MB实现的。然后  
我们跳转到init/main.c中的start\_kernel，这个函数被定位到PAGE\_OFFSET+某一个地址。  
这看起来有些狡猾。要注意到在head.S中启动分页机制的代码是通过让它自己所执行的地  
址空间不再有效的方式来实现这一点的；因此0－4MB被映射（不明白：hence the 0-4MB  
identity mapping.）。在分页机制没有启动之前，start\_kernel是不会被调用的，我们假  
定他运行在PAGE\_OFFSET+某一个地方的位置。因此head.S中的页表必须同样映射内核代码  
所使用的地址，这样后继才能跳转到staert\_kernel处；因此PAGE\_OFFSET被映射（不明  
白：hence the PAGE\_OFFSET mapping.）。  
下面在head.S中分页机制启动时的一些神奇的代码：  
/\*  
\* Enable paging  
\*/  
3:  
movl $swapper\_pg\_dir-\_\_PAGE\_OFFSET,%eax  
movl %eax,%cr3 /\* set the page table pointer.. \*/  
movl %cr0,%eax  
orl $0x80000000,%eax  
movl %eax,%cr0 /\* ..and set paging (PG) bit \*/  
jmp 1f /\* flush the prefetch-queue \*/  
1:  
movl $1f,%eax  
jmp \*%eax /\* make sure eip is relocated \*/  
1:  
在两个1的label之间的代码将第二个label 1的地址加载到EAX中，然后跳转到那里。这  
时，指令指针寄存器EIP指向1MB＋某个数值的物理地址。而label都在内核的虚拟地址空  
间(PAGE\_OFFSET+某个位置)，所以这段代码将EIP有效的从物理地址空间重新定位到了虚  
拟地址空间。  
Start\_kernel函数初始化了所有的内核数据，然后启动了init内核线程。Start\_kernel中  
最初的几件事情之一就是调用setup\_arch函数，这是一个和具体的体系结构相关的设置函  
数， 调用了更底层的初始化细节。对于x86 平台而言， 这些函数在  
arch/i386/kernel/setup.c中。  
在setup\_arch 中和内存相关的第一件事就是计算低端内存(low-memory) 和高端内存  
(high-memory)的有效页的数目；每种内存类型(each memory type)最高端的页的数目分别  
保存在全局变量highstart\_pfn和highend\_pfn中。高端内存并不是直接映射到内核的虚拟  
内存(VM)中；这是后面要讨论的。  
接下来，setup\_arch 调用init\_bootmem 函数以初始化启动时的内存分配器(boot-time  
memory allocator)。Bootmem内存分配器仅仅在系统boot的过程中使用，为永久的内核数  
据分配页。因此我们不会对它涉及太多。需要记住的就是bootmem 分配器(bootmem  
allocator)在内核初始化时提供页，这些页为内核专门预留，就好像他们是从内核景象文  
件中载入的一样，他们在系统启动以后不参与任何的内存管理活动。  
初始化内核页表  
之后，setup\_arch调用在arch/i386/mm/init.c中的paging\_init函数。这个函数做了一些  
事情。首先它调用pagetable\_init函数去映射整个的物理内存，或者在PAGE\_OFFSET到4GB  
之间的尽可能多的物理内存，这是从PAGE\_OFFSET处开始。  
在pagetable\_init函数中，我们在swapper\_pg\_dir中精确的建立了内核的页表，映射到  
截至PAGE\_OFFSET的整个物理内存。  
这是一个将正确的数值填充到页目录和页表中去的简单的算术活。映射建立在  
swapper\_pg\_dir中，即kernel页目录；这也是初始化页机制时所使用的页目录。（当使用  
4MB的页表的时候，直到下一个4MB边界的虚拟地址才会被映射在这里，但这没有什么，  
因为我们不会使用这个内存所以没有什么问题）。如果有这里有剩下物理内存没有被映射，  
那就是大于4GB－PAGE\_OFFSET范围的内存，这些内存只有CONFIG\_HIGHMEM选项被设置后  
才能使用（即使用大于4GB的内存）。  
在接近pagetable\_init函数的尾部，我们调用了fixrange\_init为编译时固定的虚拟内存  
映射预留页表。这些表将硬编码到Kernel中的虚拟地址进行映射，但是他们并不是已经加  
载的内核数据的一部分。Fixmap表在运行时调用set\_fixmap函数被映射到物理内存。  
在初始化了fixmap之后，如果CONFIG\_HIGHMEM被设置了，我们还要分配一些页表给kmap  
分配器。Kmap允许kernel将物理地址的任何页映射到kernel的虚拟地址空间，以临时使用。  
这很有用，例如对在pagetable\_init中不能直接映射的物理内存进行映射。  
Fixmap 和kmap 页表们占据了kernel 虚拟空间顶部的一部分——因此这些地址不能在  
PAGE\_OFFSET映射中被永久的映射到物理页上。由于这个原因，Kernel虚拟内存的顶部的  
128MB就被预留了（vmalloc分配器仍然是用这个范围内的地址）。（下面这句实在是不知  
道怎么翻译） Any physical pages that would otherwise be mapped into the  
PAGE\_OFFSET mapping in the 4GB-128MB range are instead (if CONFIG\_HIGHMEM is  
specified) included in the high memory zone, accessible to the kernel only via  
kmap()。如果没有设置CONFIG\_HIGMEM，这些页就完全是不可用的。这仅针对配置有大量内  
存的机器（900多MB或者更多）。例如，如果PAGE\_OFFSET=3GB，并且机器有2GB的RAM，  
那么只有开始的1GB-128MB的物理内存可以被映射到PAGE\_OFFSET和fixmap/kmap地址范  
围之间。剩余的页是不可用的——实际上对于用户进程映射来说，他们是可以直接映射的页  
——但是内核不能够直接访问它们。  
回到paging\_init，我们可以通过调用kmap\_init函数来初始化kmap系统，kmap\_init简  
单的缓存了最先的kmap\_pagetable\[在TLB？\]。然后，我们通过计算zone的大小并调用  
free\_area\_init 去建立mem\_map 和初始化freelist，初始化了zone 分配器。所有的  
freelist被初始化为空，并且所有的页都被标志为reserved（不可被VM系统访问）；这  
种情况之后会被纠正。  
当paging\_init完成后，物理内存的分布如下\[注意在2.4的内核中这不全对\]：  
0x00000000: 0-page  
0x00100000: kernel-text  
0x????????: kernel\_data  
0x???????? =\_end: whole-mem pagetables  
0x????????: fixmap pagetables  
0x????????: zone data (mem\_map, zone\_structs, freelists &c)  
0x???????? =start\_mem: free pages  
这块内存被swapper\_pg\_dir和whole-mem-pagetables映射以寻址PAGE\_OFFSET。  
进一步的VM子系统初始化  
现在我们回到start\_kernel。在paging\_init完成后，我们为内核的其他子系统进行一些  
额外的配置工作，它们中的一些使用bootmem分配器分配额外的内核内存。从内存管理的观  
点来看，这其中最重要的是kmem\_cache\_init，他初始化了slab分配器的数据。  
在kmem\_cache\_init 调用之后不久，我们调用了mem\_init。这个通过清除空闲物理页的  
zone数据中的PG\_RESERVED位在free\_area\_init的开始完成了初始化freelist的工作；  
为不能被用为DMA的页清除PG\_DMA位；然后释放所有可用的页到他们各自的zone中。最后  
一步，在bootmem.c 中的free\_all\_bootmem函数中完成，很有趣。他建立了伙伴位图和  
freelist描述了所有存在的没有预留的页，这是通过简单的释放他们并让free\_page\_ok  
做正确的事情。一旦mem\_init被调用了，bootmem分配器就不再使用了，所以它的所有的  
页也会被释放到zone分配器的世界中。  
段  
段用来将线性地址空间划分为专用的块。线性空间是被VM子系统管理的。X86体系结构从硬  
件上支持段机制；你可以按照段+段内偏移量的方式指定一个地址，这里地址被描述为一定  
范围的线性（虚拟地址）并带有特定的属性（如保护属性）。实际上，在x86体系结构中你  
必须使用段机制。所以我们要设置4个段：  
一个kernel text段：从0 到4GB  
一个kernel data段：从0 到4GB  
一个user text段：从0 到4GB  
一个user data段：从0 到4GB  
因此我们可以使用任何一个有效的段选择器(segment selector)访问整个虚拟地址空间。  
问题：  
段是在哪里被设置的？  
答案：  
全局描述符表（GDT）定义在head.s的450行。 GDT寄存器在250行被加载。  
问题：  
为什么将内核段和用户端分离开。是否他们都有权限访问整个4GB的范围？  
答案：  
这是因为内核和用户段的保护机制有区别：  
.quad 0x00cf9a000000ffff /\* 0x10 kernel 4GB code at 0x00000000 \*/  
.quad 0x00cf92000000ffff /\* 0x18 kernel 4GB data at 0x00000000 \*/  
.quad 0x00cffa000000ffff /\* 0x23 user 4GB code at 0x00000000 \*/  
.quad 0x00cff2000000ffff /\* 0x2B user 4GB data at 0x00000000 \*/  
段寄存器(CS，DS等)包含有一个13位的描述符表的索引，索引指向的描述符告诉CPU所选  
择的段的属性。段选择器的低3位没有被用来索引描述符表，而是用来保存描述符类型（全  
局或局部）以及需要的特权级。因此内核段选择器0x10和0x18使用特权级0（RPL0），用  
户选择器0x23和0x2B使用最特权级RPL 3。  
要注意到第三个高序字节的高位组对应内核和用户也是不同的：对内核，描述符特权级  
（DPL）为0；对用户DPL为3。如果你阅读了Intel的文档，你将看到确切的含义，但是由  
于Linux内核的x86段保护没有涉及太多，所以我就不再讨论太多了。