Linux 内存管理机制

桃扇骨 2021-12-16 11:39 361阅读 0赞

**1.内存空间布局：**

对于提供了MMU（存储管理器，辅助操作系统进行内存管理，提供虚实地址转换等硬件支持）的处理器而言，Linux提供了复杂的存储管理系统，使得进程所能访问的内存达到4GB。

进程的4GB内存空间被人为的分为两个部分--用户空间与内核空间。用户空间地址分布从0到3GB(PAGE\_OFFSET，在0x86中它等于0xC0000000)，3GB到4GB为内核空间。

内核空间中，从3G到vmalloc\_start这段地址是物理内存映射区域（该区域中包含了内核镜像、物理页框表mem\_map等等），比如我们使用 的 VMware虚拟系统内存是160M，那么3G～3G+160M这片内存就应该映射物理内存。在物理内存映射区之后，就是vmalloc区域。对于 160M的系统而言，vmalloc\_start位置应在3G+160M附近（在物理内存映射区与vmalloc\_start期间还存在一个8M的gap 来防止跃界），vmalloc\_end的位置接近4G(最后位置系统会保留一片128k大小的区域用于专用页面映射)

对于32bit Linux系统来说，一般留给用户态空间是3GB，高地址的1GB  0xC0000000~0xFFFFFFFF是留给kernel的。

并且一般采用分页，分段，段页式的方式。一页大小一般为2^12=4096=4KB的大小。一般是10+10+12

**2.内存管理基本机制；分段，分页，段页。**

**3.linux系统一般内存管理方法：两种算法相配合**

内存结构是：NUMA（Non-Uniform Memory Acess Architecture）架构，Numa下分布式的一个内存节点成为Node，我们常用的单击系统，是UMA（Uniform Acess Architecture）就是一个NODE，因此可以理解为一台机器就是一个NODE，每个NODE下物理内存分成几个的ZONE（区域），Zone内再对物理页进行管理。因此内存的整个管理结构是：

分布式集群——Node——Zone——Page

集群系统   ——本地一台机器——BUDDY算法——SLAB或（SLUB）算法。。。。不同区域对应的管理算法。

其中Zone的结构可以通过 /proc/buddyinfo来查看。

Node 0, zone DMA 4 4 3 3 3 3 2 1 0 0 2  
Node 0, zone DMA32 0 1 1 1 1 1 1 0 3 3 699  
Node 0, zone Normal 1180 748 514 83 18 26 21 7 2 0 1899  
Node 1, zone Normal 258 1634 379 135 47 10 2 1 1 1 2965

上面可以看到，本地一共分为两个Node，其中Node 0，包括Zone DMA，Zone DMA32，Zone Normal。。。Node 1 只有Zone Normal。。。

但是传统的X86系统包括三个Zone,DMA,Normal,HIGHMEM最后一个是高端内存区域，指的是896MB~（最大1GB）。

**①BUDDY算法概述，**伙伴系统，就是一开始就把内存分为1,2，4,8，...个页面，然后用链连起来，一般定义MAX\_ORDER为11，也就是最大可以分配2^10=1024个page，当调用allocate\_pages()，他分配2^order个连续的物理页，返回一个指针，指向第一个页，失败了返回NULL。

另外，在gfp.h中定义的几个宏定义需要说一下：

GFP\_KERNEL,GFP\_aTOMIC,GFP\_NOIO,GFP\_NOFS,GFP\_USER,GFP\_HIGHUSER,GFP\_IO,GFP\_FS,

一般最常用的就是Kernel选项，会引起阻塞，普通优先级。然后再中断情况下，就必须使用非阻塞的标志Atomic，一般内核编程主要使用则两个。

**②Solaris-SLAB算法**，用高速缓存来描述不同的对象，每种对象对应一个高速缓存。高速缓存由SLAB来管理对象的内存分配。每个SLAB是一个或多个连续的物理页（这个是从buddy算法分配而来的）一般运行在BUDDY的下层。有Slab\_full Slab\_partial,Slab\_empty,三种。通过查看/proc/slabinfo可以看到slab的使用情况。另外，由于很多进程刚开始创建时，内存格式占用大小都差不多，系统经常需要创建和销毁进程，这样导致效率很低，slab算法，每次分配相同类型的内存时，就从相应的SLAB中去取已经划分好的对象。SLAB释放的内核空间，并没有完全释放，可以留给下次分配用。。。slab的实现大都放在  mm/slab.c中。  通过查看/proc/slabinfo可以看到，

name <active\_objs> <num\_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active\_slabs> <num\_slabs>

size-131072 2 2 131072 1 32 : tunables 8 4 0 : slabdata 2 2 0  
size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0  
size-65536 1 1 65536 1 16 : tunables 8 4 0 : slabdata 1 1 0  
size-32768 4 4 32768 1 8 : tunables 8 4 0 : slabdata 4 4 0  
size-16384 31 31 16384 1 4 : tunables 8 4 0 : slabdata 31 31 0  
size-8192 573 573 8192 1 2 : tunables 8 4 0 : slabdata 573 573 0  
size-4096 875 877 4096 1 1 : tunables 24 12 8 : slabdata 875 877 0  
size-2048 759 812 2048 2 1 : tunables 24 12 8 : slabdata 406 406 1  
size-1024 2744 2916 1024 4 1 : tunables 54 27 8 : slabdata 729 729 0  
size-512 1335 1552 512 8 1 : tunables 54 27 8 : slabdata 194 194 2  
size-256 3611 3735 256 15 1 : tunables 120 60 8 : slabdata 249 249 2  
size-64 11054 11859 64 59 1 : tunables 120 60 8 : slabdata 201 201 0  
size-128 6392 6570 128 30 1 : tunables 120 60 8 : slabdata 219 219 0  
size-32 96304 96992 32 112 1 : tunables 120 60 8 : slabdata 866 866 3  
kmem\_cache 150 150 2688 1 1 : tunables 24 12 8 : slabdata 150 150 0

第一个参数是name，这个那么其实就是 调用函数  kmem\_cache\_creat（）传递的第一个参数，后面要讲这个函数。可以看到objsize乘以objperslab得到中总的大小，基本接近于分配的页大小，比如2048\*2=4096正好等于一个页，当然384\*10=3840也是接近于一个页，可能是还没有分配出去，也有一部分是slab自身的结构占用了一些空间，最后一项显示，这样的slab一共有多少个。

**下面来看一下kmem\_cache\_creat**(const char \*name,size\_t size,size\_t align,unsigned long flag,void(\*ctor)(void\*,struct kmem\_cache \*,unsigned long));

第一个参数就是制定这个高速缓存的名称，会出现在slabinfo的第一项，因为申请的一块高速缓存，是有slab来管理的。

第二项，分配的大小，对应上面就是2048,384,768等。如果是首次分配，那么开辟一个页，以后该对象的地址被回收之后，还可以由其他该类对象使用。

第三项，对齐方式，一般为0.标准对齐。

第四项，flag，SLAB\_HWCACHE\_ALIGN，使用slab内的对象按硬件的cache line进行对齐，提高性能，但是浪费内存多些。。

第五项，构造函数，传递的是函数的地址，以前还有dtor，2.6.30以后的版本中已经没有了。

调用成功，就返回一个指向该高速缓存结构的指针，然后就可以通过kmem\_cache\_alloc进行内存对象的分配了。

kmalloc函数-\_\_do\_kmalloc(size\_t size,gfp\_t flags,void \*caller).

这个函数很简单，首先从高速缓存中找到一个kmem\_cache，能够满足size大小，然后从这个kmem\_cache中分配内存对象，而这些size实际上就是在slabinfo中的大小。

kmalloc(50,GFP\_KERNEL)那么就从上面的size-64的slab中进行分配的。上面有那么的标示已经分配给其他对象了。使用kmalloc将会从未分配的高速缓存块中，分配一个能满足要求的最小高速缓存块。而这些size-xxx的slab是系统在内存初始化的时候㐇预先建立一组预定义大小的kmem\_cache，从32字节开始，一直增加到131072个字节，也就是2^32，unsigned int;

另外内存分配还定义了一些其他函数，比如kzalloc():和malloc类似，但是分配的空间置0。 kcalloc(size\_t n,size\_t size gfp\_t flag):for array。滴啊用kzalloc（n\*size,flag）,地址赋值为0；

**最后我们来看一下内存映射，mmap,munmap,msync;**

mmap()系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后，进程可以像访问普通内存一样对文件进行访问，不必再调用read()，write（）等操作。   
注：实际上，mmap()系统调用并不是完全为了用于共享内存而设计的。它本身提供了不同于一般对普通文件的访问方式，进程可以像读写内存一样对普通文件的操作。而Posix或系统V的共享内存IPC则纯粹用于共享目的，当然mmap()实现共享内存也是其主要应用之一。 （来自百度百科）

void \*mmap(void \*,size\_t length,int prot,int flag,int fd,off\_t offset);

void \*unmap(void \* addr,size\_t length)

第一项：参考虚拟地址，一般为NULL，自动生成。

第二项：字节数。

第三项：映射属性，PROT\_EXEC，PROT\_READ，PROT\_WRITE，PROT\_NONE。可以比特或。同时读写执行。

第四项：映射的操作，MAP\_SHARED，MAP\_PRIVATE，MAP\_ANONYMOUS，前两个是共享内存或者私有映射，对内存的操作都是基于copy-on write，写实复制，只用调用munmap,或者msync的时候，才能保证写回文件。

如果指定为MAP——ANONYMOUS，标示匿名映射，不映射到任何文件中，致死后fd和offset不起作用，mmap返回一块初始化为0的匿名映射内存区域块。使用malloc函数分配虚拟内存时，小于128K的的用brk（）系统调用增长堆的大小，大于128kb的直接用MAP\_ANONYMOUS的方式，映射一个匿名地址空间。开发人员可以用这种方法预先建立一个大的虚拟地址空间，实现自己的内存管理。

其他：

**内存分配  kmalloc与malloc与vmalloc的关系**（转自http://blog.csdn.net/macrossdzh/article/details/5958368）

**简单的说：**

1.  kmalloc和vmalloc是分配的是内核的内存,malloc分配的是用户的内存
2.  kmalloc保证分配的内存在物理上是连续的,vmalloc保证的是在虚拟地址空间上的连续,malloc不保证任何东西(这点是自己猜测的,不一定正确)
3.  kmalloc能分配的大小有限,vmalloc和malloc能分配的大小相对较大
4.  内存只有在要被DMA访问的时候才需要物理上连续
5.  vmalloc比kmalloc要慢

**详细的解释：**

kmalloc和get\_free\_page申请的内存位于物理内存映射区域，而且在物理上也是连续的，它们与真实的物理地址只有一个固定的偏移，因此存在较简单的转换关系，virt\_to\_phys()可以实现内核虚拟地址转化为物理地址：

而vmalloc申请的内存则位于vmalloc\_start～vmalloc\_end之间，与物理地址没有简单的转换关系，虽然在逻辑上它们也是连续的，但是在物理上它们不要求连续。

vm\_struct链表，将free的内存链接起来，记录vmalloc说得到的所有的块。

转载于:https://www.cnblogs.com/xindufresne/p/4769921.html