Axvisor内存分配器设计文档

[bullhh]

Axvisor内存分配器设计文档

1. 引言

1.1 背景

axvisor作为基于ArceOS的Hypervisor，内存管理是其核心基础设施。当前内存分配器架构存在多内存区域支持不足、大页面分配效率不高、长期运行稳定性问题等问题，需要设计新的架构以满足虚拟化环境的特殊需求。

1.2 设计目标

• 多内存区域管理：支持动态添加和管理多个不连续内存区域
• 虚拟化性能优化：优化虚拟机大页面内存分配效率
• 长期运行稳定性：建立健康的内存生态系统，避免内存碎片和泄漏
• 多核优化：减少锁竞争，提高并行分配效率

2. 当前架构分析与问题

2.1 Level-1单级TLSF分配器（当前默认）

axvisor通过alloc-level-1特性启用Level-1架构：

工作流程：

1. 所有内存请求（无论大小）都直接由TLSF分配器处理
2. TLSF直接管理全部free物理内存区域
3. 支持动态添加多个内存区域到TLSF内存池

优势：

• 架构简单，实现成本较低
• TLSF提供O(1)分配/释放性能
• 支持动态内存区域添加
• 适合实时系统场景

局限性：

• 大页面分配效率不是最优
• 长期运行可能存在内存碎片问题

2.2 Level-2两级分配器架构（理论存在但实际不可用）

虽然代码中存在Level-2的实现，但由于bitmap分配器的限制，实际上不可用：

// allocator/src/bitmap.rs
impl<const PAGE_SIZE: usize> BaseAllocator for BitmapPageAllocator<PAGE_SIZE> {
    fn add_memory(&mut self, _start: usize, _size: usize) -> AllocResult {
        Err(AllocError::NoMemory) // unsupported - 不支持动态添加内存
    }
}

Bitmap分配器架构限制：

1. 单一连续内存模型：

   pub struct BitmapPageAllocator<const PAGE_SIZE: usize> {
       base: usize,           // 基址，1GB对齐
       total_pages: usize,    // 总页面数  
       used_pages: usize,     // 已使用页面数
       inner: BitAllocUsed,   // 内部bitmap分配器
   }

2. 单一基址对齐机制：

   fn init(&mut self, start: usize, size: usize) {
       // 计算基址，强制1GB对齐
       self.base = crate::align_down(start, MAX_ALIGN_1GB); // 0x4000_0000
       
       // 计算在bitmap中的相对位置
       let start_idx = (start - self.base) / PAGE_SIZE;
       self.inner.insert(start_idx..start_idx + self.total_pages);
   }

为什么add_memory难以实现：

1. 多区域管理能力缺失：bitmap分配器设计假设单一连续内存空间
2. 基址对齐约束限制：1GB对齐要求限制了多区域支持
3. 内部算法的连续性假设：底层bitmap-allocator库基于连续性假设

2.3 当前架构的根本性问题

1. 多内存区域支持不足：bitmap分配器无法有效管理不连续内存区域
2. 大页面分配效率低：bitmap扫描方式在大块分配时性能下降明显
3. 内存生态不健康：缺乏有效的内存回收机制

3. 内存分配器技术分析

3.1 主流操作系统内存分配器

3.1.1 通用操作系统的设计哲学

主流操作系统（如Linux、Windows）的需求与TLSF的设计目标存在根本差异，linux内存分配器实现为：

应用层 → glibc malloc (ptmalloc) → 系统调用 → Linux内核
    ↓
内核空间：Buddy System (物理页) + SLUB/SLAB (内核对象)
    ↓
硬件抽象层：NUMA感知、内存热插拔等

设计特点：

• 多级混合架构：不同层次使用不同分配策略
• 吞吐量优先：优化多核并发下的平均性能
• 碎片控制：针对长期运行服务的碎片优化
• 通用性：适应从嵌入式到数据中心的各类场景

3.1.2 为什么主流操作系统不采用TLSF作为核心分配器

特性	TLSF (实时系统)	通用操作系统 (Linux/Windows)
首要目标	确定性、最坏情况性能	吞吐量、平均性能
锁策略	全局锁或简单锁机制	复杂的无锁/细粒度锁
内存视图	连续内存池管理	虚拟内存+物理页帧管理
工作负载	相对固定、可预测	极其多样、不可预测

具体技术差异：

1. 多核可扩展性：TLSF的全局锁成为多核瓶颈，而Linux的SLUB使用每CPU缓存
2. 虚拟内存支持：通用系统需要复杂的虚拟内存管理，TLSF设计为物理内存管理
3. 工作负载适应性：通用系统需要适应从字节到GB的各种需求

3.2 Buddy+Slab vs Bitmap+TLSF架构对比

3.2.1 架构概述

当前架构（Bitmap+TLSF）

内存请求分类：
├── 小内存(<4KB) ──→ TLSF字节分配器 (O(1)分配, O(1)释放)
└── 大内存(≥4KB) ──→ Bitmap页分配器 (O(n)分配, O(1)释放)

目标架构（Buddy+Slab）

内存请求分类：
├── 小内存(<4KB) ──→ Slab字节分配器 (O(1)分配, O(1)释放)
└── 大内存(≥4KB) ──→ Buddy页分配器 (O(log n)分配, O(log n)释放)
└── 多区域支持   ──→ MultiRegionBuddyPageAllocator

3.2.2 内存生态完整性对比

Buddy+Slab：双向流动的健康生态

Slab层 ↔ Buddy层
    ↓     ↓
动态分配 → 动态回收
空Slab批量回收 → 页帧返还Buddy → 伙伴块合并 → 更大块可用

Bitmap+TLSF：单向流动的架构缺陷

TLSF层 (字节级) ──→ Bitmap层 (页面级)
       ↓                 ↓
释放路径止步于 TLSF 空闲链表
       ↓
Bitmap 无法感知空闲页，无法回收/合并

真实影响：

• 回收路径被截断，Bitmap 永远拿不到释放的页帧，导致大块永远得不到补充。
• 归还机制只停留在“理论上可行”，实际实现缺失，使长期运行的碎片不断累积。

3.3 内存分配器核心原理

3.3.1 Buddy System原理

基本概念与设计思想

Buddy分配器是一种基于二分伙伴关系的页面分配算法，其核心思想是：

1. 内存组织：将物理内存按2的幂次方大小组织成块（4KB、8KB、16KB...）
2. 伙伴关系：任何两个大小相同的块，如果它们的地址仅有一位不同，则互为伙伴
3. 分裂与合并：
   • 分配：找到大小合适的块，若过大则递归分裂
   • 释放：将释放的块与伙伴合并成更大的块

分配与释放算法

分配算法流程：

1. 大小转换：将请求大小转换为对应的Order（2^n ≥ 请求大小）
2. 链表查找：在对应Order的空闲链表中查找可用块
3. 块分裂：如果当前Order无可用块，向更高Order递归分裂
4. 分配完成：返回合适大小的内存块

释放算法流程：

1. 块释放：将释放的块加入对应Order的空闲链表
2. 伙伴检测：检查"伙伴"块是否空闲
3. 块合并：如果伙伴块空闲，合并为更大的块
4. 递归合并：向上递归合并，直到无法合并为止

Buddy分配过程示例

Buddy分配过程示例：
初始状态: [空闲: 32KB]

分配8KB过程:
1. 分裂32KB → [分配: 8KB, 空闲: 8KB, 空闲: 16KB]
2. 分配8KB → [分配: 8KB, 分配: 8KB, 空闲: 16KB]

释放8KB过程(释放第一个8KB):
1. 释放8KB → [空闲: 8KB, 分配: 8KB, 空闲: 16KB]
2. 合并伙伴 → [空闲: 16KB, 分配: 8KB]

3.3.2 Slab分配器原理

基本概念与设计思想

Slab分配器是一种针对小对象优化的固定大小分配器，其核心思想是：

1. 分类分配：将小对象按大小分类（8B、16B、32B...2048B）
2. 页面容器：每个Slab使用一个或多个页面，按固定槽位大小划分
3. 三级管理：
   • 空Slab：完全未分配
   • 部分Slab：部分槽位已分配
   • 满Slab：完全分配

Slab分配过程示例

Slab分配过程示例(32字节对象):
初始化: 
┌─────────────────────┐
│ 32字节槽位1        │ ← 空闲
│ 32字节槽位2        │ ← 空闲
│ ...               │
│ 32字节槽位N        │ ← 空闲
└─────────────────────┘

分配后:
┌─────────────────────┐
│ 32字节槽位1        │ ← 已分配
│ 32字节槽位2        │ ← 空闲
│ ...               │
│ 32字节槽位N        │ ← 空闲
└─────────────────────┘

3.4 Per-CPU缓存设计原理与价值

3.4.1 多核环境下的内存分配挑战

在现代多核处理器环境中，传统的全局锁内存分配器面临严重的性能瓶颈：

锁竞争问题：

• 多个CPU核心同时访问全局分配器时，必须串行化获取锁
• 随着CPU核心数量增加，锁竞争呈指数级增长
• 高频内存分配场景下，锁成为系统性能瓶颈

缓存一致性开销：

• 多个CPU修改同一数据结构时，需要通过缓存一致性协议同步
• 频繁的缓存行失效导致性能下降
• 跨NUMA节点访问增加内存延迟

性能扩展性限制：

• 传统分配器在单核上性能良好，但多核扩展性差
• 吞吐量随CPU核心数增加而饱和甚至下降

3.4.2 Per-CPU缓存的核心设计思想

Per-CPU缓存通过将内存分配资源分散到各个CPU核心，从根本上解决了多核环境下的性能问题：

资源分散化：

传统全局分配器:
CPU0 ──┐
CPU1 ──┼──→ 全局分配器 (单点瓶颈)
CPU2 ──┤
CPU3 ──┘

Per-CPU缓存分配器:
CPU0 ──→ 本地缓存0
CPU1 ──→ 本地缓存1
CPU2 ──→ 本地缓存2
CPU3 ──→ 本地缓存3

无锁快速路径：

• 每个CPU核心优先从自己的本地缓存分配内存
• 预先分配一批对象，通过空闲链表管理，实现快速分配
• 对象释放后不立即归还系统，而是保留在池中供后续使用

Slab组织结构

三层抽象模型：

1. 对象层(Object Layer)

   • 最小分配单元，用户请求的直接目标
   • 同一Slab内所有对象大小相同
   • 对象在Slab内连续排列，便于管理

2. Slab层(Slab Layer)

   • 由一个或多个连续页面组成的基本管理单元
   • 每个Slab专门管理一种大小的对象
   • 包含对象状态位图和空闲对象链表

3. 缓存层(Cache Layer)

   • 管理多个Slab的容器，每种对象大小对应一个缓存
   • 维护三类Slab链表：完全空闲、部分使用、完全使用
   • 负责Slab的创建、销毁和对象分配策略

分配与释放机制

对象分配流程：

1. 快速路径：从部分使用Slab的空闲链表获取对象
2. 中速路径：若无部分使用Slab，从完全空闲Slab获取
3. 慢速路径：若无空闲Slab，向伙伴系统申请新页面创建Slab

4. 新内存分配架构设计

4.1 架构层次与职责

新架构基于模块化设计原则，将内存分配功能完全封装在allocator模块中，axalloc模块仅作为轻量级适配层：

层次	组件	主要职责	核心算法
适配层	axalloc模块	系统初始化、内存检测、标准库集成	-
全局分配器	GlobalAllocator	智能分配策略、统计信息、接口统一	智能路由算法
字节分配器	SlabByteAllocator	小对象分配（≤2KB）	Slab固定分配算法
页面分配器	BuddyPageAllocator	页面级分配（≥4KB）、大对象支持	Buddy伙伴算法
抽象接口	PageAllocator Trait	统一页面分配接口、实现解耦	抽象接口规范
物理内存	hypervisor管理的连续内存	提供物理内存资源	-

4.2 核心数据结构与接口设计

4.2.1 全局协调器接口

/// 全局分配器 - 协调层核心
pub struct GlobalAllocator {
    buddy: BuddyPageAllocator,
    slab: SlabByteAllocator,
    stats: UsageStats,
}

impl GlobalAllocator {
    /// 初始化首个内存区域
    pub fn init(&self, start_vaddr: usize, size: usize) -> AllocResult<()>;
    
    /// 动态添加内存区域
    pub fn add_memory(&self, start_vaddr: usize, size: usize) -> AllocResult<()>;
    
    /// 智能分配 - 根据大小自动选择分配器
    pub fn alloc(&self, layout: Layout) -> AllocResult<NonNull<u8>>;
    
    /// 分配页面
    pub fn alloc_pages(&self, num_pages: usize, align_pow2: usize) -> AllocResult<usize>;
    
    /// 释放内存
    pub fn dealloc(&self, ptr: NonNull<u8>, layout: Layout) -> AllocResult<()>;
    
    /// 释放页面
    pub fn dealloc_pages(&self, pos: usize, num_pages: usize) -> AllocResult<()>;
}

4.2.2 页面分配器接口

/// 页面分配器抽象接口
pub trait PageAllocator {
    /// 分配指定数量的页面
    fn alloc_pages(&self, num_pages: usize, align_pow2: usize) -> AllocResult<usize>;
    
    /// 释放指定范围的页面
    fn dealloc_pages(&self, pos: usize, num_pages: usize) -> AllocResult<()>;
    
    /// 获取页面统计信息
    fn get_stats(&self) -> &BuddyStats;
}

/// Buddy页面分配器 - 执行层核心
pub struct BuddyPageAllocator {
    global_pool: SpinNoIrq<BuddySet>,
    per_cpu_pools: percpu::StaticCell<PerCpuPool>,
    stats: BuddyStats,
}

4.2.3 Buddy分配器内部结构

/// Buddy集合 - 核心算法实现
pub struct BuddySet {
    free_lists: [LinkedList; MAX_ORDER],  // 各阶空闲链表
    base_addr: usize,                     // 基地址
    total_pages: usize,                   // 总页数
}

/// Per-CPU内存池
pub struct PerCpuPool {
    small_cache: SmallChunkCache,        // 1-4页缓存
    local_set: BuddySet,                  // 本地Buddy集合
    balance_timer: usize,                 // 平衡计时器
}

/// 小块缓存 - 优化热点分配
pub struct SmallChunkCache {
    chunks: [Option<usize>; 4],         // 1-4页缓存块
    heads: [usize; 4],                   // 各大小链表头
}

4.2.4 Slab字节分配器接口

/// 字节分配器抽象接口
pub trait ByteAllocator {
    /// 分配指定大小的字节
    fn alloc(&self, size: usize, align: usize) -> AllocResult<NonNull<u8>>;
    
    /// 释放指定指针和大小
    fn dealloc(&self, ptr: NonNull<u8>, size: usize, align: usize) -> AllocResult<()>;
}

/// Slab字节分配器 - 执行层核心
pub struct SlabByteAllocator<const N: usize, const MAX_CPUS: usize> {
    global_caches: [SpinNoIrq<SlabCache>; N],      // 全局Slab缓存
    per_cpu_caches: percpu::RawCell<PerCpuSlabCache<N>>, // Per-CPU缓存
    page_allocator: &'static BuddyPageAllocator,   // 页面分配器引用
}

4.2.5 Slab分配器内部结构

/// Slab缓存 - 管理特定大小对象的Slab
pub struct SlabCache {
    empty_slabs: LinkedList,     // 空Slab链表
    partial_slabs: LinkedList,   // 部分使用Slab链表
    full_slabs: LinkedList,      // 满Slab链表
    obj_size: usize,             // 对象大小
}

/// Per-CPU Slab缓存
pub struct PerCpuSlabCache<const N: usize> {
    local_caches: [LocalObjectCache; N],  // 各size class的本地缓存
    low_watermark: usize,                 // 低水位线
    high_watermark: usize,                // 高水位线
}

/// 本地对象缓存 - 无锁快速路径
pub struct LocalObjectCache {
    freelist: LinkedList,      // 空闲对象链表
    current_slab: Option<*mut SlabMeta>,  // 当前使用的Slab
    cached_bytes: usize,       // 缓存字节数
}

4.3 Buddy页面分配器设计

4.3.1 角色与约束

Buddy 层承担“页帧银行”的职能：它要把平台暴露的多个不连续可用区整合为统一库存，再按需向 Slab 或直接向调用方出售大块页帧。为了在 GlobalAllocator 自举前运行，它需要满足以下硬性约束：

• 零堆依赖：所有元数据由 const 数组、percpu 段或页帧自身承载，避免 Vec / Box。
• 多区域即插即用：modules/axalloc 传入 &[MemoryRegionDescriptor] 后即可即时拆块，无需长驻列表。
• 多核友好：提供SMP默认场景，首页调用必须命中本地缓存或本地 BuddySet，跨核锁仅在极端路径出现。
• 天然和 Slab 协作：Slab 需要从 Buddy 借页建 cache，空 Slab 又要批量归还页帧，因此 Buddy 的接口不仅是“按阶分配”，还要暴露批量借还与用量统计。

4.3.2 Buddy分配算法

核心数据结构

结构	职责	备注
BuddyPageAllocator	实现 PageAllocator trait，封装全局/本地池与统计	modules/axalloc 只与它交互
BuddySet	每阶链表 + 合并/拆分算法	被全局池与本地池重复使用
PerCpuPool	SmallChunkCache + 本地 BuddySet + 平衡计时	IRQ-off 无锁路径
SmallChunkCache	缓存 1~4 页的超热点请求	FIFO，防止抖动
BuddyStats	TOTAL_FREE_PAGES、分层水位	供平衡/监控使用

分配算法流程

alloc_pages(order)
  └─> 当前 CPU 的 PerCpuPool
        ├─ SmallChunkCache 命中 (无锁快速路径)
        ├─ local_set 命中 (IRQ-off本地路径)
        └─ pull_from_global() 失败 → 返回 Err

释放算法流程

dealloc_pages(addr, order)
  └─> 当前 CPU 的 PerCpuPool
        ├─ 直接归还 SmallChunkCache (1-4页)
        ├─ 归还 local_set (IRQ-off本地路径)
        └─ balance_to_global() (跨CPU平衡)
        └─ Buddy合并算法 (伙伴块检测与合并)

4.3.3 协作与调度策略

1. 请求分层：LOCAL_ORDER（通常覆盖 0~18 阶）之内的请求优先由当前 CPU 处理；更高阶由 global_pool 以 SpinNoIrq 保护处理。
2. 库存平衡：target_local_pages = TOTAL_FREE_PAGES / MAX_CPUS，每个 PerCpuPool 以该值为基准执行“借/还”批处理，防止单核屯货。
3. 与 Slab 的闭环：
   • Slab 需要新页建 cache → 调 BuddyPageAllocator::alloc_pages(order)。
   • Slab 空页批量回收 → 调 dealloc_pages()，Buddy 立即把块合并回链表。
   • Buddy 的 BuddyStats 为 Slab 提供“可借额度”，防止 Slab 在系统内存紧张时继续扩张。

4.4 Slab字节分配器设计

4.4.1 角色与协作定位

Slab 层是“字节粒度前哨站”：它屏蔽高频的小对象波动，让 Buddy 只需处理页面级事件。为了维持该定位，Slab 在架构上遵循以下原则：

• 固定 size class（8B~2KB）：减少管理开销并与 UsageKind 对齐。
• per-CPU 首选路径：LocalObjectCache 在 IRQ-off 区域内完成 push/pop，99% 的请求不会触发锁。
• 批量借还页面：从 Buddy 借入整页，按槽位分发；当 Slab 空置时整页归还，保持供/需平衡。
• 零堆自举：所有 cache 元数据都位于静态数组或页首 SlabMeta 中，便于与 Buddy 同步启动。

4.4.2 Slab分配算法

核心组件

结构	职责	关键交互
SlabByteAllocator	实现 ByteAllocator，桥接 Buddy	通过 page_allocator: &'static BuddyPageAllocator 借页
SlabCache	每个 size class 的 empty/partial/full 队列	提供批量 refill / evict
PerCpuSlabCache	保存 9 个 LocalObjectCache 与水位线	运行期无锁 fast-path
LocalObjectCache	freelist + 当前 slab + cached_bytes	触发 refill_from_global / drain_to_global

分配算法流程

alloc(size, align)
  └─> 计算size class (8B~2KB)
        └─> 当前CPU的LocalObjectCache
              ├─ fast path: 直接从freelist获取 (无锁)
              ├─ refill path: cached_bytes < low_watermark
              │    ├─ 从SlabCache.partial获取槽位
              │    └─ 若partial为空，向Buddy借页创建新Slab
              └─ 慢速路径: 需要锁的全局操作

释放算法流程

dealloc(ptr, size, align)
  └─> 计算size class
        └─> 当前CPU的LocalObjectCache
              ├─ 直接推入freelist (无锁)
              ├─ drain path: cached_bytes > high_watermark
              │    ├─ 将一半槽位推回SlabCache.partial
              │    └─ 若整页无人使用，直接调用BuddyPageAllocator::dealloc_pages()
              └─ 更新UsageKind统计

4.4.3 运行路径与Buddy的联动

1. Fast Path：alloc() → 当前 CPU LocalObjectCache::alloc_fast()，直接弹出 freelist。
2. Refill Path：cached_bytes < low_watermark 时，取一半 SlabCache::partial 槽位；如果 partial 为空，则向 Buddy 借整页并初始化 SlabMeta。
3. Drain Path：cached_bytes > high_watermark 时，把一半槽位推回 SlabCache::partial；若整页无人使用，直接调用 BuddyPageAllocator::dealloc_pages()。
4. 统计回传：LocalObjectCache 更新 UsageKind::{SlabBytes, SlabPages}，GlobalAllocator 因而知道 Slab 是否在快速消耗或归还页帧，可据此调整阈值策略。

4.4.4 初始化顺序（与 Buddy 同步）

1. BuddyPageAllocator::bootstrap() 完成后立即向 Slab 暴露首批页面。
2. SlabByteAllocator::bootstrap() 初始化 global_caches / percpu 段，并为每个 size class 设定 low/high watermark。
3. 次级 CPU 通过 percpu::init_secondary() 调用 PerCpuSlabCache::init_local()，确保在 AP 上下文也能无锁分配。
4. 运行期，所有 alloc/dealloc 先命中 Slab；只有当对象大于 2 KB 或 Slab 暂缺页面时才退回 Buddy。这种"先 Slab、后 Buddy、再回 Buddy"的闭环正是 4.1 所述生态的关键。

4.5 分配器协作机制

4.5.1 智能分配路由

全局分配器根据请求大小自动选择最优分配器：

请求大小 → 分配器选择流程:
┌─────────────┐    判断大小   ┌─────────────────┐
│  分配请求     │ ──────────→ │   大小分类       │
└─────────────┘             └────────┬────────┘
                                     │
         ≤2KB? ──────┬───────┐       │
         是          │    否  │       │
           ↓        │          ↓      │
    ┌─────────────┐ │  ┌─────────────┐ │
    │ Slab分配器   │ │  │ Buddy分配器  │ │
    └─────────────┘ │  └─────────────┘ │
                    │                  │
                    └────────────────┘

4.5.2 双向流动的内存生态

Slab层 ↔ Buddy层
    ↓     ↓
动态分配 → 动态回收
空Slab批量回收 → 页帧返还Buddy → 伙伴块合并 → 更大块可用

这种双向流动机制解决了原有架构的"单向流动"缺陷：

• 分配路径：Buddy大块 → Slab小对象 → 应用程序
• 回收路径：应用程序 → Slab空闲对象 → 空Slab → Buddy页帧 → 伙伴合并

4.5.3 Per-CPU缓存平衡机制

Per-CPU缓存平衡流程:
┌─────────────────┐    定期检查    ┌─────────────────┐
│ 当前CPU缓存     │ ──────────→ │ 水位比较        │
└────────┬────────┘             └────────┬────────┘
         │                              │
   低于低水位?                    高于高水位?
         │                              │
    ┌────┴────┐                ┌───────┴──────┐
    │ 向全局   │                │ 向全局归还   │
    │ 借入     │                │ 多余缓存     │
    └─────────┘                └────────────┘

4.6 初始化与运行流程

4.6.1 系统启动流程

系统启动流程:
axruntime
    ↓
axhal::mem::available_regions()
    ↓
modules/axalloc::init_system_memory()
    ↓
┌─────────────────────────────────────────┐
│ 1. BuddyPageAllocator::bootstrap()      │
│    - 首个内存区域初始化                  │
│    - 切分为2^n块并注入global_pool        │
└─────────────────────────────────────────┘
    ↓
┌─────────────────────────────────────────┐
│ 2. SlabByteAllocator::bootstrap()       │
│    - 借用MIN_HEAP_SIZE页帧              │
│    - 初始化全局缓存和per-cpu缓存         │
└─────────────────────────────────────────┘
    ↓
┌─────────────────────────────────────────┐
│ 3. 其余内存区域add_memory()             │
│    - 动态添加到Buddy分配器               │
│    - 触发split_to_chunks与伙伴合并        │
└─────────────────────────────────────────┘
    ↓
系统就绪，开始响应内存分配请求

4.6.2 运行期分配流程

运行期分配流程:
应用程序调用axalloc::alloc()
    ↓
GlobalAllocator::alloc()
    ↓
根据大小分类:
├─ ≤2KB → SlabByteAllocator::alloc()
│    ├─ LocalObjectCache快速路径 (无锁)
│    ├─ refill路径 (可能需要向Buddy借页)
│    └─ 全局路径 (需要锁)
└─ >2KB → BuddyPageAllocator::alloc_pages()
     ├─ SmallChunkCache快速路径 (1-4页)
     ├─ PerCpuPool本地路径 (IRQ-off)
     └─ 全局池路径 (需要锁)

4.7 Axalloc适配层设计

4.7.1 极简适配层实现

//! Axvisor内存分配器适配层
//! 
//! 这个模块主要负责：
//! 1. 提供与现有axalloc代码兼容的接口
//! 2. 处理平台相关的内存管理

// 重新导出allocator模块的核心接口
pub use crate::allocator::{
    global_allocator, global_init, global_add_memory,
    alloc, dealloc, realloc,
    alloc_pages, dealloc_pages,
    get_memory_stats
};

/// 系统内存区域检测
pub fn detect_memory_regions() -> Vec<MemoryRegion> { ... }

/// 初始化系统内存（自动检测内存区域）
pub fn init_system_memory() -> AllocResult { ... }

4.7.2 使用方式

use axvisor_allocator::{global_init, global_add_memory, init_system_memory};

// 初始化内存
global_init(0x80000000, 0x10000000); // 初始化256MB内存区域
global_add_memory(0x90000000, 0x8000000); // 添加128MB内存区域

5. 架构优势与实现价值

5.1 性能优势分析

5.1.1 大页面分配效率提升

场景对比：分配1GB连续内存

分配器	时间复杂度	实际性能	碎片化影响
Bitmap	O(n)	扫描262,144位	严重
Buddy	O(log n)	直接查找Order 18链表	轻微

性能提升：大页面分配效率提升巨大，特别是在内存碎片化场景下。

5.1.2 多核扩展性优化

Per-CPU缓存优势：

• 无锁快速路径：大多数分配请求无需获取全局锁
• 批量操作：减少锁获取次数，提高吞吐量
• CPU亲和性：优先使用本地缓存，提高缓存命中率

性能指标：

• 分配延迟：Per-CPU缓存命中时，延迟仅为几纳秒级别
• 吞吐量：通过并行分配，整体吞吐量随CPU数量线性增长
• 内存利用率：动态平衡机制确保内存有效利用，避免浪费

5.3 长期运行稳定性

5.3.1 内存碎片控制

Buddy系统优势：

• 自动合并机制，长期运行保持大块内存可用性
• 2的幂次方分配，减少外部碎片
• 定期碎片整理，进一步优化内存布局

Slab系统优势：

• 固定大小分配，消除内部碎片
• 对象回收机制，提高内存利用率
• 空Slab回收，释放无用内存

5.3.2 内存泄漏防护

引用计数机制：

• 跟踪内存分配来源，便于调试
• 自动检测未释放内存，防止泄漏
• 内存使用统计，监控系统健康状态

6. 总结

Axvisor内存分配器重新设计基于对现有架构问题的深入分析和对主流操作系统设计理念的学习，采用Buddy+Slab两级分配架构，通过Per-CPU缓存优化多核性能，实现了以下关键改进：

1. 多内存区域支持：解决了bitmap分配器无法管理不连续内存的根本问题
2. 大页面分配优化：Buddy算法将大页面分配从O(n)优化到O(log n)
3. 多核性能提升：Per-CPU缓存实现无锁快速路径，提高并行分配效率
4. 内存生态健康：双向流动机制确保长期运行稳定性

[bullhh]

当前内存分配器存在的BUG

一、BUG1

现象

1. 重复释放内存导致内核崩溃
2. 内核崩溃现象与重复释放位置有关，现象不一致
3. qemu中不出现，开发板中出现
4. Arceos在某些场景下可能触发该错误，这会导致查找BUG原因困难

原因

1. 底层tlsf内存分配器不支持重复释放内存，这会导致内存分配器链表错乱
2. 底层tlsf内存分配器要求上层使用时保证不重复释放，但allocator中未实现这项工作

二、BUG2

现象

1. 客户机内存和物理内存非1:1映射时，Arceos客户机启动失败
2. qemu中不出现，开发板中出现

原因

1. 应该是页表映射错误，具体错误点还需分析