实时操作系统内存管理-TLSF算法

starnight531

已于 2023-06-30 20:57:38 修改

阅读量1.1k

点赞数 2

分类专栏：风后奇门 - Linux 文章标签：操作系统内存管理 TLSF rust 嵌入式

于 2023-05-12 21:32:28 首次发布

本文链接：https://blog.csdn.net/buptsd/article/details/130650292

版权

风后奇门 - Linux 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

hhhtsdyzx

内存管理-TLSF算法

前言

前言

Vue框架：从项目学Vue
OJ算法系列：神机百炼 - 算法详解
Linux操作系统：风后奇门 - linux
C++11：通天箓 - C++11
Python常用模块：通天箓 - Python

TLSF算法：

实时操作系统的内存管理算法
TLSF的分配速度快，但是相对内存利用率低，容易出现内部碎片，比较常用于嵌入式场景。

为什么内存又叫内存“块”：

假设我们现在新买了一个16G内存条，在我们没安装到主板前，其实使用内存就不足16G：
- 初始内存中有两个指针，一个指向首个可用空间首地址，一个指向内存条“末尾”
- 首个可用空间大小为16G-2*sizeof(pointer)，而内存条末位的这个“哨兵块”大小为0
由此有了内存“块”称呼来源1：初始内存只有两块，“空闲块”&“哨兵块”
在16G内存中找空闲块指针很简单，直接111…111111，但是找哨兵块指针就需要技巧了
- 看图中哨兵块指针近邻内存块指针，所以只需要111…111111 - sizeof(pointer)就找到了
- 这里sizeof(pointer)是指以111…111111作为首地址的单元的size
- 也就是说我们需要知道当前指针所在“单元”的size，而这个size可不always等于sizeof()的结果，如分配拿到了64字节，但是我们没用完64字节，只存了一个int，此时sizeof()=4
- 所以除了这两个指针之外，其他内存块都需要一个size字段，表明自己大小
- 到这，我们可画出内存的物理“块”的结构初稿（哨兵块size不准确）：
由此有了内存“块”称呼来源2：每个内存块都有size字段规定本块大小
我们借助一个物理块的size字段可以轻松找到其物理地址的下一块，那么上一块还需要借助其他信息吗？
- 如果只要求到达上一块，则当前块块首指针-1就到了上一块的最后一个字节
- 但是要求到达上一块的块首地址，我们还是需要借助指针，这个指针就在上一块的最后sizeof(Pointer)个字节
- 由此我们可以画出物理空间上的内存块定稿：
为了防止用户直接操作物理内存，OS给用户可操控的地址/指针，其实是size邻接的下一地址：
当用户用满了这个Busy Block区域，prev_phys_block字段被用作用户数据，就不再指向物理块首地址了，
这个时候我们需要通知下一个物理块，prev_phys_block指针失效
通知的方法很简单，由于每个物理块大小size+sizeof(size字段)都是8Bytes或者4Bytes的倍数，所以每个物理块的size最后两位必定是0。
用size字段第0位标识当前物理块是不是空闲，第1位标识上一物理块是不是空闲。1是空闲，0是被用户使用。这就是为什么要求申请到的内存必须是4或者8的整数倍。
当上一个物理块被malloc()给用户使用，走之前需要把自己的size第0位置为0，把下一个物理块的size第1位置为0
每个物理块在查找上一个物理块块首时，必须先看size第1位是不是1，是1的话pre_phy_block才有效
由此有了内存“块”称呼来源3：每个内存块都要知道上一个块是不是被用户使用
最后，就像我们写链表时候的逻辑地址和物理地址一样，在控制物理块的时候，我们要借助struct做一些逻辑上的改变：
- 每个物理块开头是size，结尾是pre_phys_blocks
- 逻辑Block struct在物理块基础上多加了上一块的结尾，prev_phys_blocks，用于找到上一块的struct起始地址
- struct的起始地址始终在物理块的起始地址前一个指针大小
由此有了内存“块”称呼来源4：os通过struct来管理每个内存块

O(1)查找空闲块：

根据牺牲空间才能换取时间的原则，TLSF有着设计优越的管理结构便于查找空闲块
- 空闲内存（上图size字段）相近的空闲块串成链表，最终有许多条空闲链表
- blocks[][]：二维数组，一级索引成为fl，二级索引称为sl，每个一级索引fl下都有同样个sl，一般是2^5个，blocks[fl][sl]存储空闲链表头
- fl_bitmap：位图，为1的位说明blocks[fl]下有空闲链表，0则无。
- sl_bitmap[]：位图数组，当确定fl后，sl_bitmap[fl]是位图，为1的位说明blocks[fl][sl]下有空闲链表
- 当blocks[fl][sl]不为None，则sl_bitmap[fl]第sl位必须1，则fl_bitmap第fl位必须1。
- 位图和blocks[][]必须时刻相符合，不然说明OS已经奔溃，内存条也受伤。
```
    pub fn init_on_heap(mut tmp : Box<TLSFControl,Global>) -> Box<Self,Global>{
        // TODO: YOUR CODE HERE
        tmp.fl_bitmap = 0;
        tmp.sl_bitmap = [0; FL_INDEX_COUNT];
        for i in 0..FL_INDEX_COUNT {
            for j in 0..SL_INDEX_COUNT {
                tmp.blocks[i][j] = RawList::new();
            }
        }
        tmp
        // END OF YOUR CODE
    }
```
TLSF规定，空闲内存不同块按照下面的原则链接到不同的Blocks[fl][sl]中：
1. fl = 0层存放空闲内存不超过256Bytes的空闲块
  
  fl = 0，sl 有32个索引，256 / 32 = 8，则不同空闲范围对应sl如下：
```
/*fl = 0
sl[0]: 0  ~  7
sl[1]: 8  ~  15
sl[2]: 16  ~  23
...
sl[30]: 240 ~ 247
sl[31]: 248 ~ 255
*/
```
2. fl = 1层存放空闲内存介于256到511Bytes(256和511二进制最高位1占位同)的空闲块
  
  511 - 256 + 1 = 256，256 / 32 = 8，则不同空闲范围对应sl如下：
```
/*fl = 1
sl[0]: 256  ~  263
sl[1]: 264  ~  271
sl[2]: 272  ~  279
...
sl[30]: 596 ~ 403
sl[31]: 404 ~ 511
*/
```
3. fl = 2层存放空闲内存介于512到1023Bytes(512和1023二进制最高位1占位同)的空闲块
  
  1023 - 512 + 1 = 512，512 / 32 = 16，则不同空闲范围对应sl如下：
```
/*fl = 2
sl[0]: 512  ~  527
sl[1]: 528  ~  543
sl[2]: 544  ~  559
...
sl[30]: 992 ~ 1007
sl[31]: 1008 ~ 1023
*/
```
4. 其余fl层分配相同

确定fl：

提出需求size大小空间，如何确定fl & sl：

首先要对size进行8字节对齐:

    pub fn malloc<T>(&mut self, size: usize) -> *mut T {
        let adjust = if size > 0 {
            align_up(size, ALIGN_SIZE)
        } else {
            panic!("size must be greater than 0");
        };
        //size = adjust 或之后直接以adjust传参...

当size < 256Bytes时，先到fl = 0查找空闲块。
当size > 256Bytes时，根据公式查找空闲块：[ ]表示向下取整
$fl = [log_{x}^{size}]$

上述公式从值相等角度可用取二进制最高位1所在位代替：

#[inline]
fn ffs(word: usize) -> u32 {
    (word as u32).trailing_zeros() as u32
}

确定sl：

当size < 256Bytes时，sl = (size - 0) / 8
当size > 256Bytes时，根据公式查找空闲块：SLI就是每个fl对应sl数目取log2
$\frac{(size - 2^{fl})}{2^{f}/2^{SLI}}$
也就是特殊在size<256时候，2^fl = 2^0 = 1 != 0

提级申请：

若此时申请大小为519的空闲内存：
1. 519对8向上取整得到520
2. 520二进制最高位是第9位，因为fl=0对应的256最高位是第8位，所以fl = 9-8+1=2
3. sl = (520 - 512)/16 = 0
4. 看上面表：sl[0]: 512 ~ 527，仿佛可用blocks[2][0]
5. 但是由于不确定blocks[2][0]内空闲大小是512还是527，就有可能容不下520Bytes内容
6. 确保每次申请的空闲块都能存储下size，我们向空闲更大的blocks发起申请
寻找空闲更大且最靠近size的空闲块：
1. 从低到高查询sl_bitmap[fl]中第x位，要求x>sl，且x位上是1
2. 如果在sl_bitmap[fl]中没有查到x，则要到fl_bitmap中查询
3. 从低到高查询fl_bitmap中第x位，要求x>fl，且x位上是1

分割块：

假设现在内存条1024字节，初始两个指针占用8字节，则可用1008字节

1008字节分为大小是1008的可用块和大小是0的哨兵块

现在只申请8字节，根据上面查找fl和sl方法，肯定查到的空闲块是1008
我们不可能把远大于用于申请大小的空闲块直接给用户使用，这样内部碎片很多，所以需要分割块，将一个且不能分割出size是0的块。
给定Block struct A，分割为大小为a的B块 & 和大小不为0的C块：
1. B块直接改改使用原A的size字段，分割后我们在物理层要为C块增加size，而这个size的开销是8
2. 要确保A.size > a + 8，由于最小单元8字节，所以等价于A.size >= a + 8 + 8
确定C块size的起始位置：
- 用户data_ptr + 当前块size = 下一物理块size结尾
- 下一块size的起始位置 = 结尾 - 8
- 由于用户申请malloc到的内存块要写入用户数据，所以分割得到的C块的prev_phys_blocks失效，要设置C块size第1位为0，防止C块通过混乱的prev_phys_blocks访问其他内存。
还要设置C块的pre_phys_block，原A块下一块的pre_phys_block
如果在malloc阶段没有和8字节对齐，那么当前块的size最后2位必定失效，引起内存访问混乱。