PerFace
前面我们一起花了八篇文章，站在硬件的角度对内存有了一定的认识。但是其实当我们实际对内存进行操作的时候，是使用软件的方式。于是乎，是时候站在软件的角度来学习内存了。
在本系列的开篇之际，请允许我首先用两幅精美的图片【图片来自-摩斯电码】，来展示内存的概要，同时在本系列的开始，我会和大家一起先简要花一篇来回顾一下内存的硬件。学而时习之，不亦说乎！
期待我们一起学习完这个系列后，能对这两个图片，展开长篇阔论。
图一：linux中的内核消耗图解
图二：Linux内存管理大图
站在硬件角度看内存
1、硬件角度
大家都曾经看过那个纸上打孔，记录数据的图片。
后来都知道出现了内存器，我们执行指令分为加载+运行。
最开始的程序运行时只能跑一个进程的，那就不需要复杂的内存管理，把我弄到固定的位置，然后这片区域都是我的。而且有多大的内存我就用多大的，一旦我进程想用的内存比拥有的物理内存大的时候，崩了就完事了。
特点：单进程 单操作系统 直接使用物理内存
这样的问题随着时代的发展问题就来了。
问题一 ：单进程用不完资源那不是浪费？
问题二 ：我要是物理内存不够，又没钱升级硬件怎么办？
问题三 ：因为我的软件直接操作接触的物理内存，这个和硬件靠的太近，我们都知道移植性就查了？
随着发展单进程肯定是不符合要求的，那么怎么办？多进程（脑子里先把进程调度的事情放下，focu内存方面）。
多进程之间的这个内存怎么处理，总不能让腾讯的数据访问到快播的吧，想象你正在看剧，突然内容变成了学习内容，怕怕。为了解决这个问题，在操作系统编译的时候主存划分了很多的静态分区。有进程的时候，你就看看哪里能放下你，你去那里待着。
于是问题又来了
1、程序大小那不是必须和分区匹配，起码不能比分区小
2、这个进程的数目那就是固定了啊，那不是买电脑还得多一个电脑能跑多少个进程的参数
3、地址空间固定，进程不能膨胀啊。（想想咱们平时LOL，不运行的时候几个G，运行起来几百个，那肯肯定是玩不了了）
4、进程之间的边界真的能控制的很好吗？现在这么完备的内存管理下还经常出现内存踩踏时间。
解决方法就是前辈们整了个动态的分区，就是给操作系统整一个分区，剩下的有进程时，需要多大分割多大。这样一整，敏感的你就知道了，分割多了，那不是内存的这个空洞就多了，碎片就多了，那咋整呢。得规整内存，只能迁移进程了，迁移进程你不可能做，只能操作系统了，而这个过程很消耗时间（自己磁盘整理过的都知道哈），需要大量数据的换入换出。尤其是在进程运行的时候内存不够了，然后你得去迁移，等个一个小时，电脑我都想砸了。
迁移只有这个进程的位置也变了，这个寻址方式就算是相对寻址，那个相对的对象总是绝对的，因此程序编写你就说头疼不。（两数之和已经够头疼了，还有心情去管理内存重定位）
同时当这个程序是恶意的，那我不是就可以为所欲为，因为大家都是直接对应的物理内存，我偏不去我该去的地方，我就在你工作的时候来骚扰你一下，你就说怕不怕。
于是这几个问题：
内存保护、内存运行重定位、使用效率低下无法忍受
懒惰是催促科技进步的源动力
1、解决办法 level1 - 分段机制
为了解决进程间内存保护的问题，提出了虚拟内存。
通过增加一层虚拟内存，进程访问虚拟内存，虚拟内存由操作系统映射到物理内存。
对于进程来说它就不需要关系实际的物理地址，当访问到没有映射的物理内存时，操作系统会捕捉到这个微法操作。
同时进程是使用的虚拟内存，因为程序也具有移植性
但是啊进程就算是操作虚拟内存但是最后也是映射到物理内存，如果给进程映射的物理内存不够的时候，那还是得迁移。换出到磁盘进行迁移，粒度是整个进程，这么大的io肯定很漫长。
想想一个程序中的数据，在不断的运行使用的只有那么一部分，于是把常用的放在内存，不常用的放在磁盘中。那么换入换出的就是那么一少部分数据。然后这里就创建了更细的粒度–分页机制
想想为什么你的电脑内存条才8个G却能跑几十G的游戏。
2、解决办法 level2 - 分页机制
现在我们知道分页粒度很细。进程的虚拟地址、硬件的物理地址都按照分页的粒度。
常用的代码和数据以页留在内存，不常用的去磁盘，这样就节省了物理内存（内存那么贵）
进程的虚拟内存页通过CPU的硬件单元映射到物理内存页
物理页称为物理页面或者页帧
进程空间的虚拟页面称为虚拟页
操作系统为了管控这些物理页面，给页帧创建了编号页帧号 PFN
现在的页表常见的4KB最常见，还有16K、64K。在某些特点的场景下，比如那种超大服务器系统TB量级，可能页面是M或者G级别。
到这里就说说那个CPU的硬件单元
其实虽然什么不想做的事情都扔给操作系统，但是做人不能这么狗，尤其是内存管理这么严重的事情，还有就是安全性（我这样认为），于是用过CPU的硬件单元–MMU来管控这个内存的映射。
ARM处理器的内存管理单元包括TLB和Table Walk Unit两个部件。
TLB是一块高速缓存，用于缓存页表转换的结果，从而减少内存访问的时间。就拿缓存的概念去理解。当TLB 没有，miss了。那我就只能去内存的转换页表中获取这个映射的结果，获取到对应的物理地址后再将我的虚拟地址换成物理地址去最终的目的地查看学习资料。（有没有中玩游戏闯关的感觉）
当然不是说有个这个玩意就什么不用做了。
一个完整的页表翻译和查找的过程叫作页表查询（Translation Table Walk），页表查询的过程由硬件自动完成，但是页表的维护需要软件来完成。
页表查询是一个相对耗时的过程，理想的状态是TLB里缓存有页表转换的相关信息。当TLB未命中时，才会去查询页表，并且开始读入页表的内容。（要是这个TLB整大点，不是可以加快，不考虑钱的话）
因此页表的维护是软件的，所以在Linux内核内存的学习中，后面会有内存初始化，创建页表这些东西。
3、虚拟内存到物理地址的转换
上面那个图里面，如果是TLBs命中后就直接拿到了物理地址，去兑换奖品，但是miss掉以后，那就得走Table Walk Uint就是得页表转换，VA–>PA（V：虚拟 P：物理 A：地址）
整个流程瞅瞅？
处理器根据页表基地址控制寄存器TTBCR和虚拟地址来判断使用哪个页表基地址寄存器，是TTBR0还是TTBR1。（一个基值是内核的，一个用户态的）
页表基地址寄存器中存放着一级页表的基地址。
处理器根据虚拟地址的bit[31:20]作为索引值（）4K页表，在一级页表中找到页表项。一级页表一共有4 096个页表项。
第一级页表的表项中存放有二级页表的物理基地址。处理器将虚拟地址的 bit[19:12]作为索引值，在二级页表中找到相应的页表项。二级页表有256个页表项（2^12 * 2^8 * 4kb(2^12)==》32位）。
二级页表的页表项里存放有 4KB 页的物理基地址，加上最后的VA 12位，因此处理器就完成了页表的查询和翻译工作。
（将整个4MB分成了4096份* 256份*4KB）
（这就是为什么内存越大，页表项也得越大，不然页表项的内存就变大的）
（表项存的是基地址，而虚拟内存放的都是索引）
图 7.4 所示为 4KB 映射的一级页表的表项，bit[1:0]表示一个页映射的表项，bit[31:10]指向二级页表的物理基地址。
4KB是2^12
64位的ARM 一般常用的是48，那么只剩36位（其他的位干啥了呢，记住这个问题哈哈哈）
这里还是讨论32位
一级页表 4KB页表-->4GB/4KB--->2^20个页表项--->32位地址4Byte-->那么这个页表需要4MB的连续内存
下图展示两个进程以及各自的页表和物理内存的对应关系图，这里假定页大小是4K，32位地址总线进程地址空间大小为(2^32)4G，这时候页表项有 4G / 4K = 1048576个，每个页表项为一个地址，占用4字节，1048576 * 4(B) /1024(M) = 4M，也就是说一个程序啥都不干，页表大小就得占用4M。如果每个页表项都存在对应的映射地址那也就算了，但是，绝大部分程序仅仅使用了几个页，也就是说，只需要几个页的映射就可以了，如下图，进程1的页表，只用到了0,1,1024三个页，剩下的1048573页表项是空的，这就造成了巨大的浪费，为了避免内存浪费，计算机系统开发人员想出了一个方案，多级页表。
我们先看下图，这是一个两级页表，对应上图中的进程1。先计算下两级页表的内存占用情况。
一级页表占用= 1024 * 4 B= 4K，
2级页表占用 = (1024 * 4 B) * 2 = 8K。
总共的占用情况是 12K，相比一级页表 4M，节省了99.7%的内存占用。
我们来看下两级页表为啥能够节省这么大的内存空间，相比于上图单级页表中一对一的关系，两级页表中的一级页表项是一对多的关系，这里是1:1024, 这样就需要 1048576 / 1024 = 1024 个一级页表项。相当于把上图的单级页表分成1024份。一级页表项PTE0表示虚拟地址页01023，PTE1表示虚拟地址页10242047。如果对应的1024个虚拟地址页存在任意一个真实的映射，则一级页表项指向一个二级页表项，二级页表项和虚拟地址页一一对应，在上图中，进程1的虚拟页0,1,1024存在映射，0,1虚拟页属于这里的PTE0,1024属于PTE1。一级页表项中如果为null，表示对应的1024个虚拟页没有使用，所以就不需要二级页表了，节省了空间。当然，如果虚拟地址页完全映射的话，多级页表的占用=一级页表项(1024 * 4B) + 二级页表项(1024 1024 4B) = 4M + 4K，比单级映射多了4K，不过这种情况基本上没有可能，因为进程的地址空间很少有完全映射的情况。正是因为省却了大量未映射的页表项使得页表的空间大幅减少。
其实这个差异就是我以前一来就把全部的虚拟页表和物理页表建立了映射关系，那我这个页表就需要4M。
现在我将这个4M的页表分成了1024份，需要几份就申请创建几份页表，而不是一来就把所有的页表都和物理页面挂上钩。
然后分成了这1024个，我需要在抽象一层4kb的页表去指向这1024个页表各自的基地址。
因为从物理内存层面一层一层的提到最上层的时候，也方便我们对于这个虚拟地址的组成：
一级页表索引+二级页表索引+VA（每次页表的内容都是下一基的基地址）
（这个图片稍微有点理想，一般都是4096 + 256的组合，而不是1014 + 1024的组合，不过大概这个道理就行）
那几个特殊的位是内存的属性。这个后面再补充。这个是ARM硬件架构上针对安全内存、设备内存的一些位。
软件角度看看内存
关于内存，从软件的角度去查看，其实作为一个软件程序员，大多数对这个维度的接触还是蛮多的。
linux中有个free命令，其就是查看系统内存的情况。
free命令的选项也比较简单，常用的参数命令如下。 -b 以Byte为单位显示内存使用情况。 -k 以KB为单位显示内存使用情况。 -m 以MB为单位显示内存使用情况。 -g 以GB为单位显示内存使用情况。 -o 不显示缓冲区调节列。 -s<间隔秒数> 持续观察内存使用状况。 -t 显示内存总和列。 -V 显示版本信息。 下面是Linux机器中使用free -m命令看到的内存情况。 $ free -m total used free shared buff/cache available Mem: 7763 5507 907 0 1348 1609 Swap: 16197 2940 13257
figo@figo-OptiPlex-9020:～$ 可以看到，这个机器上一共有7 763MB物理内存。 total：指系统中总的内存。这里有两种内存，一个是“Mem”，指的是物理内存；另一个是“Swap”，指的是交换磁盘。 used：指程序使用的内存。 free：未被分配的物理内存大小。 shared：共享内存大小，主要用于进程间通信。 buff/cache：buff指的是buffers，用来给块设备做缓存，而cache指的是page cache，用来给打开的文件做缓存，以提高访问文件的速度。 available：这是free命令新加的一个选项。当内存短缺时，系统可用回收buffers和page cache。那么availabe = free + buffers + page cache对不对呢？ 其实在现在的Linux内核中，这个公式不完全正确，因为buffers和page cache里并不是所有的内存都可以回收的，比如共享内存段、tmpfs 和 ramfs 等属于不可回收的。所以这个公式应该变成：available = free + buffers + page cache – 不可回收部分。
在我们写代码的时候也会用到malloc()这个函数，如果你申请内存没有用到，那可能是你使用的高级语言，申请内存的函数封装了malloc。
对于这些函数瞅一眼就行了，需要用的时候再好好深入学习一下这个里面的东西。了解这个API背后的实现。
下面让我们再软件层面从内存的布局和进程的角度去认识一下内存
1、从内存布局图角度看内存管理
书里面有句话写的挺好的，到达一个景区，先看看景区的地图，会让我们在里面浏览的游刃有余。（当然未知也能带来惊喜）在内存管理学习也是，这里我们来看看内存的布局，对我们的学习是会大有好处的。
我们知道Linux是分为两种状态 用户态和内核态，Linux内核需要跑在硬件平台上，硬件平台也有自己的状态。这里还是ARM，ARM有其中处理器的模式。
用户模式（user）：用户程序运行的模式。 系统模式（system）：特权模式。 一般中断模式（IRQ）：普通中断模式。 快速中断模式（FIQ）：快速中断模式。 管理模式（supervisor）：操作系统的内核通常运行在该模式下。 数据访问终止模式（abort）：当数据或者指令预取终止时进入该模式，用于虚拟存储及存储保护。未定义指令模式（undefined）：当未定义的指令执行时进入该模式，可用于支持硬件协处理器的软件仿真。
Linux内核的用户态和内核态两种模式分别对应的用户模式和管理模式。
这里还是以32位，对应4GB，内核一般内核：用户按照1：3的比例分配。这也是可以修改的。
我们知道分页机制，赋予了每个进程都有寻址4GB的空间，因为每个进程都有自己的进程表。
Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xf0000000 - 0xff000000 ( 240 MB) lowmem : 0xc0000000 - 0xef800000 ( 760 MB) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) modules : 0xbf000000 - 0xbfe00000 ( 14 MB) .text : 0xc0008000 - 0xc0658750 (6466 kB) .init : 0xc0659000 - 0xc0782000 (1188 kB) .data : 0xc0782000 - 0xc07b1920 ( 191 kB) .bss : 0xc07b1920 - 0xc07db378 ( 167 kB)
（这部分信息是在mem_init()函数中输出的。虚拟内存）
内核空间是从3GB开始，lowmem这段空间其实就是我们常说的线性映射区。（为啥虚拟地址明明在高位却是low，继续看）所谓的线性映射区，就是物理内存线性地映射到这段内核空间的区域中。在 ARM32 平台上，物理地址[0:760MB]的这一部分内存被线性映射到[3GB :3GB+760MB]的虚拟地址上（因为其物理地址在低位）。
线性映射区的虚拟地址和物理地址相差PAGE_OFFSET，即3GB。内核中有相关的宏来实现线性映射区的虚拟地址到物理地址的查找，例如__pa(x)和__va(x)。
其中，__pa()把线性映射区的虚拟地址转换为物理地址，转换公式很简单，即用虚拟地址减去PAGE_OFFSET（3GB），然后加上PHYS_OFFSET（这个值在有的ARM平台上为0，在ARM Vexpress平台上为0x6000_0000）。
物理内存被分成了两部分，低端的部分用在线性映射区，线性映射区就是这里的“lowmem”区域。剩下的高端部分的物理内存被称为高端内存（High Memory），内核要使用它，必须通过高端映射的方式来访问。
内核通常把低于760MB的物理内存称为线性映射内存（Normal Memory），而高于760MB以上的称为高端内存。
（这个高端是针对内核内存来说，780到1G）
这个分给内核的1G分成了高端和线性。
高端780到1G是干啥呢？
剩下的264MB虚拟地址空间是保留给vmalloc机制、fixmap和高端异常向量表等使用的。内核很多驱动使用vmalloc机制来分配连续虚拟地址的内存，因为有的驱动不需要连续物理地址的内存；除此以外，vmalloc机制还可以用于高端内存的临时映射。一个32位的系统中，实际支持的内存数量会超过内核线性映射的长度，但是内核要具有对所有内存的寻找能力。
（这里我想的是虽然在内核，但是我内核还是要对整个内存有个控制能力，这里就是体现，在vmalloc机制就可以干这个：个人看法，有纠正的大佬在评论区告诉小的一下）
编译器在编译目标文件并且链接完成之后，就可以知道内核映像文件最终的大小，接下来将其打包成二进制文件，该操作由arch/arm/kernel/vmlinux.ld.S 控制，其中也划定了内核的内存布局。
内核image本身占据的内存空间从_text段到_end段，并分为如下几个段。
text段：_text和_etext为代码段的起始和结束地址，包含了编译后的内核代码。
init段：__init_begin和__init_end为init段的起始和结束地址，包含了大部分内核模块初始化的数据。
data段：_sdata和_edata为数据段的起始和结束地址，保存大部分内核的已初始化的变量。
BSS段：__bss_start和__bss_stop为BSS段的开始和结束地址，包含初始化为0的所有静态全局变量。
上述几个段的大小在编译链接时根据内核配置来确定，因为每种配置的代码段和数据段长度都不相同，这取决于要编译哪些内核模块，但是起始地址_text 总是相同的。内核编译完成之后，会生成一个System.map文件，查询这个文件可以找到这些符号的具体数值。
这是整个Linux内核的输出日志绘制的内存布局图
2、进程角度看内存
上面我们对整个内核内存分布有了个大概的认识，下面再从进程的角度来看看。
在windows下的可执行文件的格式为.exe，而Linux的下的是ELF。这是一种文件格式，就是告诉你文件是怎么存储的。怎么存储什么意思？就是这玩意是什么？放在哪里？应该以什么姿势去放？
整个ELF的图看看
这些内容和内核空间定义也差不多。
代码段（.text）：程序源代码编译后的机器指令被存放在这个代码段里。 数据段（.data）：存放已初始化的全局变量和已初始化的局部静态变量。 bss段（.bss）：用来存放未初始化的全局变量以及未初始化的局部静态变量。
写一个程序，其实是依赖很多的其他的程序，因此自己写的程序需要编译链接后才能使用，对这部分有点疑惑可以自己先去看看C语言编译链接这个过程，大爷要是不想动，让我动，给你
整一篇的话，请留言哦。
时起到辅助作用，暂时先不用关注它们。程序在编译链接时会尽量把相同权限属性的段分配在同一个空间里，例如，把可读可执行的段放在一起，包括代码段、init段等；把可读可写的段放在一起，包括.data段和.bss段等。ELF把这些属性相似并且链接在一起的段叫作分段（Segment），进程在装载时是按照这些分段来映射可执行文件的。
描述这些分段的结构叫作程序头（Program Header），它描述了ELF文件是如何映射到进程地址空间的，这是我们比较关心的。
可以使用objdump或者readelf工具来查看ELF文件包含哪些段。
我们可以通过“readelf -l”命令来查看这些程序头。
在看的时候主要关注LOAD类型的分段，其他的都是在LOAD的时候起到辅助作用。
这是都是静态的。
在如果你想去看看静态的，可以通过proc文件系统来看看Linux内核的运行情况。每个进程运行之后，在/proc/pid/maps节点会列出当前进程的地址映射情况。
对于proc不了解的可以看看大帅比的文章了解一下 --------->>>>>>>Linux内核追踪（一）：proc/sys/debugfs
第1行中显示了地址0x10000～0x870000这段进程地址空间，它的属性是只读并且可执行的，由此我们知道它是代码段，也就是之前看到的代码段的程序头。
第2行中显示了地址0x96000～0x98000，它的属性是可读可写的进程地址空间，也就是我们之前看到的数据段的程序头。
第 3 行中显示了地址 0x98000～0xbb000，这段进程地址空间叫作堆空间（Heap），也就是通常使用malloc分配的内存，大小是140KB。test进程主要使用malloc分配100KB的内存，这里看到Linux内核会分配比100KB稍微大一点的内存空间。
第4行显示test进程的栈（stack）空间。
第5行是Sigpage的进程地址空间，Sigpage是ARM体系结构中特有的页面。
第6行是ARM中高端映射的异常向量（vectors）。
这里说的进程地址空间，在 Linux 内核中使用一个叫作 VMA 的术语来描述，它是vm_area_struct数据结构的简称，在虚拟内存管理部分会详细介绍它。另外，/proc/pid/smaps节点会提供更多的地址映射的细节，以代码段的VMA和堆的VMA为例。
另外，/proc/pid/smaps节点会提供更多的地址映射的细节，以代码段的VMA和堆的VMA为例。
这里就不深入去讲诉这些，毕竟咱们这是宏观篇，对内存从不同角度有个认识，有个大概的了解，目的就达到了。
参考资料：
- 《奔跑吧 linux内核》
