大家好，如果您还对彻底理解Linux内存管理（转载）不太了解，没有关系，今天就由本站为大家分享彻底理解Linux内存管理（转载）的知识，包括的问题都会给大家分析到，还望可以解决大家的问题，下面我们就开始吧！
前言
内存管理一直是所有操作系统书籍讨论的焦点。市场上和互联网上都充斥着大量与内存管理相关的教材和信息。因此，我们这里要写的Linux内存管理采取的是避重就轻的策略。从理论上讲，我们不尝试做我们想做的事，这是可笑的。我们最想做的，也是可能做的，就是从一个开发者的角度来谈谈对内存管理的理解。最终的目标是与大家分享我们在内核开发中使用内存的经验以及我们对Linux内存管理的理解。
当然，我们也会介绍段页等内存管理的一些基本理论，但我们的目的不是强调理论，而是为了指导和理解开发中的实践，所以我们就到此为止，不再赘述。
进程和内存
进程如何使用内存？
毫无疑问，所有进程（执行的程序）都必须占用一定量的内存，要么是用来存储从磁盘加载的程序代码，要么是用来存储从用户输入获取的数据等。然而，进程管理这些内存的方式根据不同的情况而有所不同。记忆的目的。有些内存是预先统一静态分配和回收的，有些则是根据需要动态分配和回收的。
对于任何普通的进程来说，都会涉及到5个不同的数据段。有一点编程知识的朋友可以认为这些数据段包括“程序代码段”、“程序数据段”、“程序堆栈段”等，是的，这些类型的数据段都包括在内，但是除了以上类型之外除了数据段之外，该进程还包含两个附加数据段。我们简单总结一下进程对应的内存空间所包含的五个不同的数据区域。
代码段：代码段用于存储可执行文件的操作指令，也就是说，它是可执行程序在内存中的映像。需要防止运行时代码段被非法修改，因此只允许读操作，不允许写（修改）操作。 —— 不可写。
数据段：数据段用于存储可执行文件中初始化的全局变量。换句话说，它存储由程序静态分配的变量和全局变量[1]。
BSS段[2]：BSS段包含程序中未初始化的全局变量。所有bss 段在内存中都设置为零。
堆：堆用于存储进程运行时动态分配的内存段。它的大小不是固定的，可以动态扩大或缩小。当进程调用malloc等函数分配内存时，新分配的内存会动态添加到堆中（堆被扩展）；当使用free等函数释放内存时，释放的内存将从堆中移除（堆减少）。
流程如何组织这些区域？
在上述内存区域中，数据段、BSS和堆通常连续存储在——个内存位置，而代码段和堆栈往往独立存储。有趣的是，堆和栈这两个区域之间的关系非常“模糊”。其中一个向下“增长”（i386架构中栈向下，堆向上），另一个向上“增长”，因此它们是相反的。但你不必担心他们会见面，因为他们之间的距离很大（你可以从下面的示例程序中计算出有多大），他们见面的机会很小。
下图简单描述了进程内存区域的分布：
“事实胜于雄辩”，我们用一个小例子（原型取自《User-Level Memory Management》）来展示上面提到的各个内存区域的区别和位置。
#include#include#includeint bss_var;int data_var0=1;int main(int argc,char **argv){ printf('下面是进程内存类型的地址\n'); printf('文本位置：\n') ; printf('\tmain地址(代码段):%p\n',main); printf('____________________________\n'); int stack_var0=2； printf('堆栈位置：\n'); printf('\t堆栈初始结尾：%p\n',stack_var0); int stack_var1=3； printf('\t新堆栈末尾：%p\n',stack_var1); printf('____________________________\n'); printf('数据位置：\n'); printf('\tdata_var的地址(数据段):%p\n',data_var0);静态int data_var1=4; printf('\tdata_var的新结尾(数据段):%p\n', data_var1); printf('____________________________\n'); printf('BSS Location:\n'); printf('\tbss_var:%p\n的地址',bss_var); printf('____________________________\n'); char *b=sbrk((ptrdiff_t)0); printf('堆位置：\n'); printf('\t堆初始结尾：%p\n',b); brk(b+4); b=sbrk((ptrdiff_t) 0); printf('\t堆的新末尾：%p\n',b);返回0； }
其结果如下：
下面是进程的memText 位置类型的地址： main（代码段）的地址：0x8048388____________________________堆栈位置：堆栈的初始结束：0xbffffab4堆栈的新结束：0xbffffab0_____________________________数据位置： data_var的地址（数据段）:0x8049758新的数据结束_var(数据段):0x804975c____________________________BSS Location: bss_var的地址：0x8049864____________________________Heap Location:堆的初始结尾：0x8049868 堆的新结尾：0x804986c
还可以使用size命令查看程序各段的大小。例如，如果执行size example，您将得到
文本数据bss dec 十六进制文件名
1654 280 8 1942 796 示例
但这些数据是程序编译时的静态统计，而上面显示的是进程运行时的动态值，但两者是对应的。
通过前面的例子，我们初步了解了进程使用的逻辑内存分布情况。这一部分我们将继续进入操作系统内核，看看进程是如何分配和管理内存的。
从用户角度到内核来说，所使用的内存表示形式会经历“逻辑地址”——“线性地址”——“物理地址”几种形式（前面已经介绍了几种地址的解释）。通过段机制将逻辑地址转换为线性地址；线性地址通过页机制转换为物理地址。 （但是我们要知道，Linux系统虽然保留了段机制，但所有程序的段地址都固定在0-4G。因此，虽然逻辑地址和线性地址是两个不同的地址空间，但在Linux中逻辑地址等于线性地址，它们的值是相同的）。沿着这个思路，我们研究的主要问题集中在以下几个问题。
1、如何管理进程空间地址？
2、进程地址是如何映射到物理内存的？
3. 物理内存是如何管理的？
以及由上述问题衍生出的一些子问题。比如系统虚拟地址分配；内存分配接口；连续内存分配和非连续内存分配等
进程内存空间
Linux操作系统采用虚拟内存管理技术，使每个进程都有自己的进程地址空间，互不干扰。该空间是一个线性虚拟空间，块大小为4G。用户看到、接触到的是虚拟地址，看不到实际的物理内存地址。使用这种虚拟地址不仅可以保护操作系统（用户无法直接访问物理内存），更重要的是用户程序可以使用比实际物理内存更大的地址空间（具体原因请参见硬件基础部分） 。
在讨论进程空间的细节之前，我们需要先明确以下问题：
l 首先，4G进程地址空间被人为地分为两部分：——用户空间和内核空间。用户空间的范围是0到3G（0xC0000000），内核空间占用3G到4G。用户进程通常只能访问用户空间的虚拟地址，而不能访问内核空间的虚拟地址。只有当用户进程进行系统调用（代表用户进程在内核态执行）时才能访问内核空间。
l 其次，用户空间对应进程，所以每当进程切换时，用户空间也会随之变化；而内核空间是由内核映射的，不会随着进程的变化而变化，是固定的。内核空间地址有自己对应的页表（init_mm.pgd），每个用户进程有不同的页表。
l 第三，各个进程的用户空间完全独立，互不相关。不信的话，你可以同时运行上面的程序10次（当然，为了同时运行，让它们一起休眠100秒再返回），你会看到10个进程占用的线性地址完全相同。
进程内存管理
进程内存管理的对象是进程线性地址空间上的内存映像。这些内存映像实际上是进程使用的虚拟内存区域（内存区域）。进程虚拟空间是一个32 位或64 位“平面”（独立连续范围）地址空间（空间的确切大小取决于体系结构）。这么大的平面空间想要统一管理并不容易。为了方便管理，虚拟空间被划分为许多大小可变（但必须是4096的倍数）的内存区域。这些区域就像进程线性地址中的停车位。按顺序排列。划分这些区域的原则是“将访问属性一致的地址空间存储在一起”。这里所谓的访问属性简单地说就是“可读、可写、可执行等”。
如果想查看某个进程占用的内存区域，可以使用命令cat /proc//maps来获取（pid是进程号，可以运行上面我们给出的例子——./example；pid会打印到屏幕上），你可以找到很多类似下面的数字信息。
由于程序示例使用了动态库，因此除了示例本身使用的内存区域外，还包括动态库使用的内存区域（区域顺序为：代码段、数据段、bss段）。
下面我们只提取与示例相关的信息。除了前两行代表的代码段和数据段外，最后一行是进程使用的堆栈空间。
08048000 - 08049000 r-xp 00000000 03:03 439029 /home/mm/src/example
08049000 - 0804a000 rw-p 00000000 03:03 439029 /home/mm/src/example
………………
bfffe000 - c0000000 rwxp ffff000 00:00 0
每行数据的格式如下：
（内存区域） 起始-结束访问权限偏移主设备号：次设备号iNode 文件。
注意，你肯定会发现进程空间只包含三个内存区域。好像没有上面提到的heap、bss等。事实上，情况并非如此。程序内存段与进程地址空间中的内存区域之间存在着模糊的对应关系，也就是说，堆、bss、数据段（已初始化）均由进程空间中的数据段内存区域来表示。
Linux内核中进程内存区域对应的数据结构是： vm_area_struct。内核将每个内存区域作为一个单独的内存对象进行管理，对应的操作是一致的。使用面向对象的方法，VMA结构可以表示各种类型的内存区域——例如内存映射文件或进程的用户空间堆栈等，并且对这些区域的操作也不同。
vm_area_strcut结构体比较复杂。其详细结构请参考相关资料。这里我们仅对其组织方法提供一点补充说明。 vm_area_struct是描述进程地址空间的基本管理单元。对于一个进程来说，往往需要多个内存区域来描述其虚拟空间。如何关联这些不同的内存区域呢？大家可能会想到使用链表。确实，vm_area_struct结构确实是以链表的形式链接起来的。不过，为了方便搜索，内核以红黑树的形式组织内存区域（以前的内核使用平衡树）来减少搜索时间。这两种并存的组织形式并不多余：链表用于需要遍历所有节点的情况，而红黑树则适合定位地址空间中特定的内存区域。内核使用这两种数据结构来实现内存区域上各种操作的高性能。
下图体现了进程地址空间的管理模型：
进程的地址空间对应的描述结构就是“内存描述符结构”，它代表了进程的整个地址空间。 ——包含了与进程地址空间相关的所有信息，其中当然也包括进程的内存区域。
进程内存分配和回收
进程相关的操作如进程创建fork()、程序加载execve()、映射文件mmap()、动态内存分配malloc()/brk()等都需要给进程分配内存。不过，此时进程申请并获得的并不是实际内存，而是虚拟内存，准确的说是“内存区域”。进程对内存区域的分配最终将归结为do_mmap() 函数（brk 调用作为单独的系统调用实现，没有do_mmap()）。
内核使用do_mmap() 函数创建一个新的线性地址范围。但说这个函数创建一个新的VMA并不是很准确，因为如果创建的地址范围与现有地址范围相邻并且它们具有相同的访问权限，那么这两个范围将合并为一个。如果无法合并，那么您确实需要创建一个新的VMA。但无论哪种情况，do_mmap() 函数都会向进程的地址空间添加一个地址范围- 无论是扩展现有内存区域还是创建新区域。
同样，要释放一块内存区域，使用函数do_ummap()，该函数会销毁相应的内存区域。
如何从虚构变成现实！
从上面我们知道，进程可以直接操作的地址都是虚拟地址。当进程需要内存时，它只是从内核获取虚拟内存区域，而不是实际的物理地址。该进程并没有获取物理内存（物理页——的概念请参考硬件基础章节），它获取的只是新的线性地址范围的使用权。在实际物理内存中，只有当进程真正访问新获得的虚拟地址时，“请求页面机制”才会产生“页面丢失”异常，从而进入分配实际页面的例程。
这个异常是虚拟内存机制存在的基本保证。它会告诉内核实际为进程分配物理页并建立相应的页表。之后，虚拟地址实际上被映射到系统的物理内存上。 （当然，如果页面换出到磁盘，也会出现缺页异常，但此时就不需要再创建页表了）
这种请求页面机制推迟了页面的分配，直到不能再推迟为止，并不急于一次性完成所有事情（这个思想有点像设计模式中的代理模式）。之所以可以这样做，是利用了内存访问的“局部性原则”。请求页面的好处是节省空闲内存，提高系统的吞吐率。要更清楚地理解请求页面机制，可以阅读《深入理解linux内核》这本书。
这里需要解释一下nopage对内存区域结构的操作。当访问的进程虚拟内存没有实际分配页面时，会调用该操作来分配实际的物理页面，并为该页面创建页表项。在最后一个示例中，我们将演示如何使用此方法。
系统物理内存管理
虽然应用程序操作的对象是映射到物理内存的虚拟内存，但处理器直接操作物理内存。所以当应用程序访问虚拟地址时，必须首先将虚拟地址转换为物理地址，然后处理器才能解析地址访问请求。地址转换需要通过查询页表来完成。综上所述，地址转换需要对虚拟地址进行分段，使得虚拟地址的每一段作为指向页表的索引，页表项指向下一级页表。或者指向最终的物理页面。
每个进程都有自己的页表。进程描述符的pgd字段指向进程的页全局目录。下面我们借用《linux设备驱动程序》的一张图，大致看一下进程地址空间和物理页的转换关系。
上述过程说起来容易做起来难。因为物理页——在虚拟地址映射到该页之前必须先分配，也就是说必须从内核获取空闲页并建立页表。接下来我们介绍一下内核管理物理内存的机制。
物理内存管理（页管理）
Linux内核通过分页机制来管理物理内存，它将整个内存划分为无数个4k（在i386架构中）的页，因此分配和回收内存的基本单位是内存页。采用分页管理有助于灵活分配内存地址，因为分配不需要大块连续内存[3]，系统可以东一页、西一页来弥补所需的内存。使用过程。即便如此，系统在使用内存时实际上还是倾向于分配连续的内存块，因为分配连续内存时，页表不需要改变，因此可以降低TLB刷新频率（频繁刷新会大大降低访问速度） 。
鉴于上述需求，为了尽量减少内核分配物理页时的不连续性，采用“伙伴”关系来管理空闲页。合伙人分配算法大家应该都很熟悉。几乎所有操作系统书籍都会提到——。我们不会详细讨论它。如果不明白的话可以参考相关资料。这里只需要了解Linux中空闲页的组织和管理是利用伙伴关系的，所以分配空闲页时需要遵循伙伴关系，最小单位只能是2页大小的幂。内核中分配空闲页的基本函数是get_free_page/get_free_pages，它们要么分配单个页，要么分配指定页（页2、4、8.512）。
注意：get_free_page在内核中分配内存，与malloc在用户空间分配内存不同。 malloc使用堆动态分配，实际上调用的是brk()系统调用。该调用的作用是扩大或缩小进程堆空间（会修改进程的brk域）。如果现有的内存区域不足以容纳堆空间，则相应的内存区域将以页大小的倍数进行扩展或收缩。不过brk值并不是按照页面大小的倍数修改的，而是按照实际请求来修改的。因此，Malloc可以在用户空间以字节为单位分配内存，但内核内部仍然会以页为单位分配内存。
另外，需要提到的是，系统中的物理页是通过页结构struct page来描述的。系统中的所有页面都存储在数组mem_map[]中，系统中的每个页面（空闲或非空闲）都可以通过这个数组找到。 ）。其中的空闲页面可以通过上述合作伙伴组织的空闲页面列表（free_area[MAX_ORDER]）进行索引。
内核内存使用情况
板坯
所谓尺愈长，寸愈短。以页为最小单位分配内存确实更方便内核管理系统中的物理内存，但是内核本身最常用的内存往往是非常小的（比页小很多）的内存块——，比如作为存储文件描述符。进程描述符、虚拟内存区域描述符和其他活动需要不到一页内存。与页面相比，用于存储描述符的内存就像面包屑。多个这样的小内存块可以聚合成一个完整的页面；这些小块内存的创建/销毁频率与面包屑一样频繁。
为了满足内核对如此小的内存块的需求，Linux系统使用了一种称为slab分配器的技术。 lab分配器的实现比较复杂，但是原理并不难。其核心思想是“存储池[4]”的使用。内存碎片（小块内存）被视为对象。使用时不会直接释放，而是缓存在“存储池”中以供下次使用。这无疑避免了频繁创建和销毁对象带来的问题。带来额外负载。
Slab技术不仅避免了内部内存碎片带来的不便（下面会解释）（引入Slab分配器的主要目的是减少伙伴系统分配算法的调用次数—— 频繁的分配和回收必然会产生内存碎片——很难找到大块连续的可用内存），并且可以很好地利用硬件缓存来提高访问速度。
Slab 并不是一种独立于伙伴关系而存在的内存分配方法。 Slab仍然是基于页面的。换句话说，Slab 将页面（来自合作伙伴管理的空闲页面链表）撕成许多小内存。分配块是为了分配。 lab中的对象分配和销毁使用kmem_cache_alloc和kmem_cache_free。
Kmalloc
板分配器不仅用于存储特定于内核的结构，还用于处理内核对小内存块的请求。当然，鉴于Slab分配器的特点，一般来说，内核程序中对小于一页的小块内存的请求都是通过Slab分配器提供的接口Kmalloc来完成的（虽然它可以分配32到131072字节）的记忆）。从内核内存分配的角度来看，kmalloc可以看作是get_free_page(s)的有效补充，内存分配粒度更加灵活。
如果有兴趣，可以去/proc/slabinfo查找内核执行站点使用的各种slab信息统计，在这里你会看到系统中所有slab的使用信息。从信息中我们可以看到，除了特殊结构使用的slab之外，还有大量为Kmalloc准备的slab（其中有一些是为dma准备的）。
内核非连续内存分配（Vmalloc）
无论伙伴关系还是slab技术，从内存管理理论的角度来看，目的基本相同。都是为了防止“分片”，但是分片又分为外部分片和内部分片。所谓Internal sharding，是指系统为了满足一小块（连续）内存区域的需要，不得不为其分配大面积的连续内存，从而造成空间的浪费；外部分片是指系统虽然有足够的内存，但是却是碎片化的，无法满足大块“连续内存”的需求。无论哪种类型的分片，它都是系统高效使用内存的障碍。 lab分配器允许一个页面中包含的许多小内存块被独立分配和使用，避免内部碎片并节省空闲内存。伙伴关系按大小来管理内存块，一定程度上减少了外部碎片的危害，因为页框分配不再是盲目的，而是按照大小有序进行。然而，伙伴关系只能缓解外部碎片化，但并不能完全消除。您可以计算出多次分配页面后剩余多少可用内存。
因此，避免外部分片的最终思路还是归结为如何利用不连续的内存块组合成“看似很大的内存块”。 —— 这里的情况与虚拟内存的用户空间分配非常相似。内存在逻辑上是连续的，但实际上映射到的物理内存不一定是连续的。 Linux内核借用这种技术让内核程序在内核地址空间中分配虚拟地址，同时也利用页表（内核页表）将虚拟地址映射到分散的内存页面。这样就完美解决了内核内存使用的外部分片问题。内核提供了vmalloc函数来分配内核虚拟内存。该函数与kmalloc不同。它可以分配比Kmalloc大得多的内存空间（可以比128K大得多，但必须是页大小的倍数）。但相比Kmalloc，Vmalloc需要重新映射内核虚拟地址，必须更新内核页表，因此分配效率较低（以空间换取时间）
与用户进程类似，内核也有一个名为init_mm 的mm_strcut 结构体来描述内核地址空间。页表项pdg=swapper_pg_dir包含了系统内核空间（3G-4G）的映射关系。因此，vmalloc在分配内核虚拟地址时必须更新内核页表，而kmalloc或get_free_page由于分配的内存是连续的，不需要更新内核页表。
vmalloc分配的内核虚拟内存和kmalloc/get_free_page分配的内核虚拟内存位于不同的区间，不会重叠。由于内核虚拟空间是由分区管理的，每个分区各司其职。进程空间地址分布从0到3G（实际上是到PAGE_OFFSET，等于0x86中的0xC0000000）。从3G到vmalloc_start的地址是物理内存映射区域（该区域包含内核映像、物理页表mem_map等）比如我使用的系统内存是64M（用free可以看到），那么（3G——3G+ 64M）这块内存应该映射到物理内存，并且vmalloc_start位置应该在3G+64M附近（我说'附近'是因为它在物理内存中）内存映射区域和vmalloc_start之间也会有8M的间隙，以防止边界跳跃），并且vmalloc_end的位置接近4G（我说‘接近’是因为系统会在最后一个位置预留一个128k的区域用于专用页映射，并且可能会有高端内存映射区域，这些是细节，我们不会在这里讨论它们）。
上图是一个模糊的内存分布轮廓。
get_free_page或Kmalloc函数分配的连续内存被困在物理映射区域中，因此它们返回的内核虚拟地址与实际物理地址仅相距一个偏移量（PAGE_OFFSET），您可以轻松地将其转换为物理内存地址。并且内核还提供了virt_to_phys()函数将内核虚拟空间中的物理映射区域地址转换为物理地址。要知道物理内存映射区域中的地址与内核页表是有序对应的。系统中的每个物理页都可以找到其对应的内核虚拟地址（在物理内存映射区域中）。
vmalloc分配的地址限制在vmalloc_start和vmalloc_end之间。 vmalloc分配的每一块内核虚拟内存都对应一个vm_struct结构（不要与vm_area_stru混淆
ct搞混，那可是进程虚拟内存区域的结构），不同的内核虚拟地址被4k大小的空闲区间隔，以防止越界——见下图）。与进程虚拟地址的特性一样，这些虚拟地址与物理内存没有简单的位移关系，必须通过内核页表才可转换为物理地址或物理页。它们有可能尚未被映射，在发生缺页时才真正分配物理页面。 这里给出一个小程序帮助大家认清上面几种分配函数所对应的区域。 #include#include#includeunsigned char *pagemem;unsigned char *kmallocmem;unsigned char *vmallocmem;int init_module(void){ pagemem = get_free_page(0); printk("<1>pagemem=%s",pagemem); kmallocmem = kmalloc(100,0); printk("<1>kmallocmem=%s",kmallocmem); vmallocmem = vmalloc(1000000); printk("<1>vmallocmem=%s",vmallocmem);}void cleanup_module(void){ free_page(pagemem); kfree(kmallocmem); vfree(vmallocmem);} 实例 内存映射(mmap)是Linux操作系统的一个很大特色，它可以将系统内存映射到一个文件（设备）上，以便可以通过访问文件内容来达到访问内存的目的。这样做的最大好处是提高了内存访问速度，并且可以利用文件系统的接口编程（设备在Linux中作为特殊文件处理）访问内存，降低了开发难度。许多设备驱动程序便是利用内存映射功能将用户空间的一段地址关联到设备内存上，无论何时，只要内存在分配的地址范围内进行读写，实际上就是对设备内存的访问。同时对设备文件的访问也等同于对内存区域的访问，也就是说，通过文件操作接口可以访问内存。Linux中的X服务器就是一个利用内存映射达到直接高速访问视频卡内存的例子。 熟悉文件操作的朋友一定会知道file_operations结构中有mmap方法，在用户执行mmap系统调用时，便会调用该方法来通过文件访问内存——不过在调用文件系统mmap方法前，内核还需要处理分配内存区域（vma_struct）、建立页表等工作。对于具体映射细节不作介绍了，需要强调的是,建立页表可以采用remap_page_range方法一次建立起所有映射区的页表，或利用vma_struct的nopage方法在缺页时现场一页一页的建立页表。第一种方法相比第二种方法简单方便、速度快， 但是灵活性不高。一次调用所有页表便定型了，不适用于那些需要现场建立页表的场合——比如映射区需要扩展或下面我们例子中的情况。 我们这里的实例希望利用内存映射，将系统内核中的一部分虚拟内存映射到用户空间，以供应用程序读取——你可利用它进行内核空间到用户空间的大规模信息传输。因此我们将试图写一个虚拟字符设备驱动程序，通过它将系统内核空间映射到用户空间——将内核虚拟内存映射到用户虚拟地址。从上一节已经看到Linux内核空间中包含两种虚拟地址：一种是物理和逻辑都连续的物理内存映射虚拟地址；另一种是逻辑连续但非物理连续的vmalloc分配的内存虚拟地址。我们的例子程序将演示把vmalloc分配的内核虚拟地址映射到用户地址空间的全过程。 程序里主要应解决两个问题： 第一是如何将vmalloc分配的内核虚拟内存正确地转化成物理地址？ 因为内存映射先要获得被映射的物理地址，然后才能将其映射到要求的用户虚拟地址上。我们已经看到内核物理内存映射区域中的地址可以被内核函数virt_to_phys转换成实际的物理内存地址，但对于vmalloc分配的内核虚拟地址无法直接转化成物理地址，所以我们必须对这部分虚拟内存格外“照顾”——先将其转化成内核物理内存映射区域中的地址，然后在用virt_to_phys变为物理地址。 转化工作需要进行如下步骤： a) 找到vmalloc虚拟内存对应的页表，并寻找到对应的页表项。 b) 获取页表项对应的页面指针 c) 通过页面得到对应的内核物理内存映射区域地址。 如下图所示： 第二是当访问vmalloc分配区时，如果发现虚拟内存尚未被映射到物理页，则需要处理“缺页异常”。因此需要我们实现内存区域中的nopaga操作，以能返回被映射的物理页面指针，在我们的实例中就是返回上面过程中的内核物理内存映射区域中的地址。由于vmalloc分配的虚拟地址与物理地址的对应关系并非分配时就可确定，必须在缺页现场建立页表，因此这里不能使用remap_page_range方法，只能用vma的nopage方法一页一页的建立。 程序组成 map_driver.c，它是以模块形式加载的虚拟字符驱动程序。该驱动负责将一定长的内核虚拟地址(vmalloc分配的)映射到设备文件上。其中主要的函数有——vaddress_to_kaddress（）负责对vmalloc分配的地址进行页表解析,以找到对应的内核物理映射地址（kmalloc分配的地址）；map_nopage()负责在进程访问一个当前并不存在的VMA页时，寻找该地址对应的物理页，并返回该页的指针。 test.c 它利用上述驱动模块对应的设备文件在用户空间读取读取内核内存。结果可以看到内核虚拟地址的内容（ok!），被显示在了屏幕上。 执行步骤 编译map_driver.c为map_driver.o模块,具体参数见Makefile 加载模块 ：insmod map_driver.o 生成对应的设备文件 1 在/proc/devices下找到map_driver对应的设备命和设备号：grep mapdrv /proc/devices 2 建立设备文件mknod mapfile c 254 0 （在我的系统里设备号为254） 利用maptest读取mapfile文件，将取自内核的信息打印到屏幕上。
用户评论
这篇文章讲得太好了！作为一名刚入门Linux系统的程序员来说，对内存管理一直有点懵逼，这下终于清晰了。作者把复杂的概念解释得通俗易懂，重点突出也很棒，读完感觉醍醐灌顶啊！
有6位网友表示赞同！
内存管理真是个坑啊，这篇文章让我明白了很多之前都没搞明白的细节，比如页面置换、交换区等等。虽然还是有些地方不太清楚，不过至少知道如何去深入学习了，感谢作者的分享！
有15位网友表示赞同！
Linux系统的内存管理确实很强大，这篇博文写的很有深度，特别是对页式和段式的对比分析非常到位，让我对不同技术的优缺点有了更深的理解。建议以后再加一些实际应用案例的讲解会更好哦！
有7位网友表示赞同！
说实话，这篇文章有点过于专业了，对于初学者来说估计很难直接吸收知识。我感觉一个好的科普文应该更加注重通俗易懂的解释和生动形象的例子，而不是像学术论文一样堆砌专业术语。
有17位网友表示赞同！
看标题以为是浅显易懂的入门教程，结果是深度解读，对一些基础概念了解不多的人来说可能有点难度。不过从评论区很多人都受益匪浅，可见作者还是传道授业解惑了！
有11位网友表示赞同！
感觉这篇文章文笔比较晦涩，逻辑性也不强，虽然讲了不少Linux内存管理的概念，但缺乏针对性的讲解和实例分析，读完文章对整体理解并没有太大的提升。
有19位网友表示赞同！
我一直在搞Linux开发，这篇博文正好能帮我补缺一些知识。尤其是关于虚拟内存的实现原理，以前总觉得不太清晰，现在经过作者的详细描述，终于理解了其中的奥妙。
有10位网友表示赞同！
赞赏文章作者对Linux内存管理深度解析，尤其对内核级调优策略的分析非常有价值！对于想要深入学习Linux系统开发的人来说，这是一篇非常实用的参考资料。
有11位网友表示赞同！
虽然这篇文章解释得很到位，但我觉得缺乏一些实际操作步骤和代码示例，这样才能更直观地帮助读者理解和记忆。希望作者能够在后续文章中补充更多实践体验。
有18位网友表示赞同！
对Linux内存管理一直感兴趣，这篇博文让我对该领域有了更好的认识，尤其是关于页表结构的介绍，非常清晰易懂。
有12位网友表示赞同！
这篇文章内容很专业，针对性也很强，对于想要深入研究Linux系统的人来说很有帮助。不过建议作者在文章开头添加一些入门前的准备知识，方便没有 Linux 基础的用户进行阅读
有5位网友表示赞同！
我看了好多关于Linux内存管理的文章，但这篇写的最透彻！尤其是对不同的内存分配策略的比较分析非常详细，让我受益匪浅。
有17位网友表示赞同！
对于初学者来说，这篇文章稍微偏专业了，有些概念需要一定的计算机原理基础才能理解。建议作者能够添加更多入门级别的讲解，帮助更多的读者快速入门 Linux 内存管理。
有20位网友表示赞同！
Linux内存管理真是太复杂了！读完这篇博文感觉我离全面掌握还很远呢。不过文章写的很有深度，值得慢慢品味和反复学习。
有7位网友表示赞同！
文章分析得非常全面，从页式到段式，再到虚拟内存，每个部分都讲解得很细致，对我的理解提昇了不少！就是不知道作者的博客还有没有其他关于Linux 内存管理的内容？
有20位网友表示赞同！
作为一个 Linux 的新手程序员，这篇深度解读虽然对我来说有些难懂，但我依然受益良多。至少从文章中我了解到 Linux 内存管理的复杂性和重要性。
有20位网友表示赞同！