Linux内存管理的slab 1:slab原理1 .为什么即使有合作伙伴系统(Buddy )也需要slab？ 1.1什么是合作伙伴系统？ 1.1.1合作伙伴系统思想1.2合作伙伴系统示例说明1.3合作伙伴系统可以解决的问题2为什么需要引入slab算法？ 2.1合作伙伴系统缺点2.2合作伙伴系统缺点示例说明3. slab可以解决什么问题？ 3.3 slab分配示例4. slab系统的核心思想是什么？ 4.1 slab核心思想：对象管理内存4.2 slab对象/内存池思想4.3 slab中的对象是什么？ 4.4 cache是内存中的空间，而不是5 slab分配的最小和最大内存单元数，这是硬件缓存4.5 lab分配器的基本原则之一。 6. slab与buddy系统的关系6.1互补6.2实际上， 合作伙伴系统将物理页6.3 slab分配为内核缓存对象7. slab适配器结构7.1 slab结构图7.2 slab结构解释7.2.1 cache _ chain7.2.2kmem _ cache7. 2 full slabs _ partial slabs _ empty7.2.2.3cache _ cache结构体等说明7.2.3 slab 8. slab和/Prab
1 .为什么有Buddy (合作伙伴系统)也需要slab？ 1.1什么是合作伙伴系统？
在Linux内核中，使用buddy system算法以页为单位管理内存，进行内存分配。
1.1.1合作伙伴系统将所有空闲页面放置在11个链表中，每个链表分别包含1、2、4、8、16、32、64、128、256、512和1024页的内存块如果系统需要分配内存，可以从buddy系统获取。
在1.2合作伙伴系统的示例中，例如，要申请一个4页连续内存，请直接从buddy系统中管理4页连续内存的链接列表中获取。 同样，如果系统需要申请三页连续内存，则只能在四页链表中获取，而剩下的一页放在buddy系统管理一页的链表中。
1.3伙伴系统可以解决的问题Buddy系统解决了物理内存分配的外部碎片问题。
Linux内存管理- buddy系统
3359 www.cn blogs.com/long Chang/p/10749392.html
为什么需要部署slab算法？ 2.1合作伙伴系统的缺点Buddy提供了一个page内存分配接口，对内核来说粒度太大，因此需要一种新的机制来将page划分为更小的单位进行管理。
2.2合作伙伴系统的一个缺点是，Linux内存以页为单位进行内存管理，buddy算法以2的n次方个页面进行内存分配管理，最小为20，即1页，最多为211，4mb的连续内存空间但是页面的粒度还是太大了。 在Linux上大小为4kb (4096字节)，但kernel本身有许多数据结构，需要始终分配和释放。 这些数据的大小通常小于4KB大小，通常只有几十字节的大小。
例如，最常用的task_struct (进程描述符)结构和mm_struct (内存描述符)结构。 其中izeof task_struct=9152，sizeof mm_struct=2064。
task_struct稍大，接近两个页面，mm_struct几乎只有一半的页面。 这样，如果所有这些数据结构都按页分配存储和管理，kernel很快就会自己玩完，内存碎片肯定会堆积如山。
因此，引入slab分配器是为了弥补内存管理粒度过大的不足。
3 .板坯能解决什么问题？ slab分配需要解决的是内存的内部碎片问题。
内部碎片整理是指由内核分配但不可用的存储器。
外部碎片是指由于经常申请和释放页面框而出现的小型连续页面框。 例如，由于只有一个页面框且无法分配给需要大连续页面框的进程而发生的内存碎片。
3.3 slab分配的示例，如果需要100字节的连续物理内存，内核slab分配器将为您提供128字节大小的连续物理存储器单元。 (与此文件的对齐值相对应，例如100字节对应于128字节，30字节对应于32字节，60字节对应于64字节，而不是对齐为100字节。 ) ) )
4. slab系统的核心思想是什么？ 4.1 slab核心思想：对象管理内存使用对象概念管理内存。
slab分配器的基本思想是首先利用页面分配器分配一组单个或连续的物理页面，然后将整个页面划分为多个相等的小存储器单元，以满足小存储器空间分配的需要。 当然，这是为了有效管理这些小内存单元，确保极高的内存使用速度和效率。
这句话摘自《深入linux设备驱动程序内核机制》
3359 blog.csdn.net/Yu zhi hui _ no1/article/details/47305361
4.2 slab对象/内存池思想在内核中经常使用一些链表。 链表中申请了很多结构相同的结构体，包括文件对象、工艺对象等。 如果申请频繁，就为它们创建内部
存池，内存池中都是相同结构的结构体，当想申请这种结构体时，直接从这种内存池中取一个结构体出来，是有用且速度极快的。一个物理页就可以作用这种内存池的载体，进而进行充分利用，减少了内部碎片的产生。所以，Slab 相当于内存池思想，且是为了解决内碎片而产生的，slab的核心思想是以对象的观点管理内存。
4.3 slab中对象是什么？所谓的对象就是存放一组数据结构的内存区，为便于理解可把对象看作内核中的数据结构（例如：task_struct,file_struct 等）。
相同类型的对象归为一类，每当要申请这样一个对象时，slab分配器就从一个slab列表中分配一个这样大小的单元出去，而当要释放时，将其重新保存在该列表中，而不是直接返回给伙伴系统，从而避免内部碎片。
4.4 cache是内存中的区域，而不是指硬件高速缓存这种场景是非常多的，为了应对这种场景，slab为这样的对象创建一个cache，即缓存。每个cache所占的内存区又被划分多个slab，每个 slab是由一个或多个连续的页框组成。每个页框中包含若干个对象，既有已经分配的对象，也包含空闲的对象。
尽管英文中使用了Cache这个词，但实际上指的是内存中的区域，而不是指硬件高速缓存
4.5 lab分配器的一个基本原则slab分配器对不同长度内存是分档的，这是slab分配器的一个基本原则，按申请的内存的大小分配相应长度的内存。
这可以先参考kmalloc的实现，kmalloc申请的物理内存长度为参数size，它需要先根据这个长度找到相应的长度的缓存
slab分配器并非一开始就能智能的根据内存分档值分配相应长度的内存。每种cache对应一种长度的slab分配。
23、………211个字节。
另外还有两个特殊的组，分别是96B和192B，共11组
所以，slab分配内存大小是：
8B，16B，32B，64B，96B，128B，192B，256B，512B，1024B，2048B等大小。共11组
**可以从 cat /proc/slabinfo 中 看到，**可见 7 查看系统中的slab对象
6. slab与buddy系统的关系 6.1 互补的slab系统与buddy系统所要解决的问题是互补的，一个解决外部碎片一个解决内部碎片，但事实上，slab在新建cache时同样需要用到buddy来为之分配页面，而在释放cache时也需要buddy来回收这此页面。也就是说，slab事实上是依赖buddy系统的。
6.2 实际还是伙伴系统分配物理页从slab的分配可以知道，其实所有的内存最终还是要伙伴系统来分配，这里就可以知道，这些内存都是连续的物理页。
6.3 slab作为内核缓存对象在某些情况下内核模块可能需要频繁的分配和释放相同的内存对象，这时候slab可以作为内核对象的缓存，当slab对象被释放时，slab分配器并不会把对象占用的物理空间还给伙伴系统。这样的好处是当内核模块需要再次分配内存对象时，不需要那么麻烦的向伙伴系统申请，而是可以直接在slab链表中分配一个合适的对象
7. slab 配器结构 7.1 slab 结构图图：
解释：
每个kmem_cache都是链接在一起形成一个全局的双向链表，由cache指向该链表，系统可以从Cache_chain开始扫描每个kmem_cache，来找到一个大小最合适的kmem_cache，然后从该kmem_cache中分配一个对象
最高层是 cache_chain,这是一个 slab 缓存的链接列表。可以用来查找最适合所需要的分配大小的缓存（遍历列表）
cache_chain 的每个元素都是一个 kmem_cache 结构的引用（称为一个 cache）。它定义了一个要管理的给定大小的对象池。
每个缓存(kmem_cache)都包含了一个 slabs 列表，这是一段连续的内存块（通常都是页面）
其中每个kmem_cache有三条链表：
对象的分配和释放都是在slab中进行的，所以slab可以在三条链表中移动，如果slab中的object都分配完了，则会移到full 链表中；如果分配了一部分object，则会移到partial链表中；如果所有object都释放了，则会移动到empty链表中；其中当系统内存紧张的时候，slabs_empty链表中的slab可能会被返回给系统。
7.2.2.3 cache_cache 结构体等说明所有的kmem_cache结构都是从cache_cache分配的
static kmem_cache_t cache_cache = { slabs_full: LIST_HEAD_INIT(cache_cache.slabs_full), slabs_partial: LIST_HEAD_INIT(cache_cache.slabs_partial), slabs_free: LIST_HEAD_INIT(cache_cache.slabs_free), objsize: sizeof(kmem_cache_t), flags: SLAB_NO_REAP, spinlock: SPIN_LOCK_UNLOCKED, colour_off: L1_CACHE_BYTES, name: "kmem_cache",};struct cache_size{size_t cs_size;struct kmem_cache *cs_cachep;}struct cache_size malloc_sizes[] = { {.cs_size = 32},{.cs_size = 64},{.cs_size = 128},{.cs_size = 256},................{.cs_size = ~0UL},};在系统初始化时，内核会调用kmem_cache_init函数对malloc_size数组进行遍历，对数组中的每个元素都调用kmem_cache_create()函数在cache_cache中分配一个struct kmem_cache 实例，并且把kmem_cache所在的地址赋值给cache_size中的cs_cachep指针
7.2.3 slabslab 列表中的每个 slab 都是一个连续的内存块（一个或多个连续页），它们被划分成一个个对象（如 mm_struct）。
这些对象是从特定缓存中进行分配和释放的基本元素。
proc 文件系统提供了一种简单的方法来监视系统中所有活动的 slab 缓存。
这个文件称为 /proc/slabinfo，
它除了提供一些可以从用户空间访问的可调整参数之外，还提供了有关所有 slab 缓存的详细信息。
如：
[root@localhost home]# cat /proc/slabinfoslabinfo - version: 2.1# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>nf_conntrack_ffffffffb58fc900 51 51 320 51 4 : tunables 0 0 0 : slabdata 1 1 0rpc_inode_cache 51 51 640 51 8 : tunables 0 0 0 : slabdata 1 1 0xfs_dqtrx 0 0 528 62 8 : tunables 0 0 0 : slabdata 0 0 0xfs_dquot 0 0 488 67 8 : tunables 0 0 0 : slabdata 0 0 0xfs_ili 2016 2016 168 48 2 : tunables 0 0 0 : slabdata 42 42 0xfs_inode 21182 21182 960 34 8 : tunables 0 0 0 : slabdata 623 623 0xfs_efd_item 39 39 416 39 4 : tunables 0 0 0 : slabdata 1 1 0xfs_btree_cur 39 39 208 39 2 : tunables 0 0 0 : slabdata 1 1 0…… 9. slab APILinux内存管理之slab 2：slab API
https://blog.csdn.net/lqy971966/article/details/112980005
参考：
https://blog.csdn.net/yuzhihui_no1/article/details/47305361
https://blog.csdn.net/qq_22238021/article/details/80214759
https://zhuanlan.zhihu.com/p/61457076
https://blog.csdn.net/rockrockwu/article/details/79976833
https://www.cnblogs.com/wangzahngjun/p/4977425.html