Linux内核CMA机制详解_连续内存分配原理配置与排障实践围绕 Linux 内核中的 CMAContiguous Memory Allocator连续内存分配器系统讲清楚它为什么存在、如何与伙伴系统协同、迁移与隔离的关键路径、驱动侧使用方式、配置方法、调试观察点和线上排障步骤。目录先回答核心问题为什么还需要 CMACMA 的设计目标与边界工作原理总览预留、复用、迁移、分配关键数据结构struct cma与位图模型初始化路径与启动阶段行为迁移路径中的核心概念MIGRATE_CMA与MIGRATE_ISOLATE驱动如何使用通过 DMA API 间接接入IOMMU 与 CMA 关系选型判定流程配置实践启动参数与设备树调试与可观测性debugfs、meminfo、dmesg常见故障与排障清单容量规划与工程建议一页速查表值班版总结免责声明延伸阅读先回答核心问题为什么还需要 CMADMA 设备摄像头、显示、编解码、AI 加速器等常要求物理连续内存。系统运行一段时间后即使“总空闲内存很多”也可能因为外部碎片无法拿到足够大的连续块。这正是 CMA 的价值它不是“只会浪费内存的静态预留”而是通过可复用预留区 需要时迁移腾挪在“利用率”和“连续性保证”之间做平衡。机制对连续内存保障对总体内存利用率纯静态 carveout高低闲时难复用纯伙伴系统低碎片化后不稳定高CMA中高依赖可迁移性中高CMA 的设计目标与边界设计目标为设备提供较稳定的大块连续物理页分配能力。在设备未占用时允许该区域被系统暂时复用。分配失败时提供可观测、可定位的排障路径。能力边界CMA 不是“任何时候都 100% 成功”的承诺其成功率依赖页面可迁移性。被长期 pin、locked 或不可迁移的页会直接影响分配结果。实时性和大块成功率依赖容量规划与负载模型不能只靠默认配置。dma_alloc_coherent()并不等于“必走 CMA”是否落到 CMA 与平台内存拓扑、DMA 约束、IOMMU/IOVA 路径和内核配置有关在有 IOMMU 的系统中很多设备可通过离散物理页映射到连续 IOVA未必依赖 CMA 提供物理连续块。工作原理总览预留、复用、迁移、分配区域足够空闲被占用启动阶段预留CMA区域标记为MIGRATE_CMA闲时可被普通分配复用设备请求连续内存直接分配隔离目标pageblockMIGRATE_ISOLATE迁移可迁移页到其他位置腾出连续空间设备DMA使用释放后回归CMA位图管理可以把它理解为先圈一块“可弹性借用”的连续内存候选区需要时通过迁移把“临时住户”搬走再把连续空间交给设备。关键数据结构struct cma与位图模型CMA 区域通常由struct cma这类结构描述核心字段常包括可结合 CMA debugfs 文档 对照理解字段含义工程意义base_pfn区域起始页帧号对应物理起点count区域总页数对应总容量bitmap分配状态位图快速查找连续空闲片段order_per_bit每 bit 对应页数2^n位图粒度与扫描效率权衡位图抽象0空闲可用。1已占用。位图本身并不解决碎片只是状态管理工具真正“腾连续块”的关键仍在页面迁移能力。初始化路径与启动阶段行为常见路径可抽象为start_kernel()-setup_arch()- 预留与登记 CMA 区域 - 初始化位图与迁移类型来源通常有两类内核启动参数如cma256M3G-4G。设备树reserved-memory节点。初始化完成后这些区域会进入 CMA 管理并与伙伴系统形成“可复用、可回收”的协同关系。迁移路径中的核心概念MIGRATE_CMA与MIGRATE_ISOLATE当设备申请连续块而目标片段已被占用时通常会发生下面流程将目标 pageblock 从MIGRATE_CMA切到MIGRATE_ISOLATE阻止新的干扰分配进入。对当前占用页执行迁移前提是页可迁移。连续区间腾空后完成分配。完成后恢复 pageblock 的迁移类型回到 CMA 常态。这个流程的本质是“先封控、再迁移、后交付、再恢复”。一句话记忆CMA 不是“天然永远连续”而是“在 pageblock 粒度通过迁移类型切换来尽量恢复连续性”。补充理解工程常见误区pageblock 是内存迁移与分配策略的重要粒度单元具体大小与内核配置相关。如果 pageblock 长期混入不可迁移页面例如 unmovable/pinned这块区域可用性会持续变差。这也是“系统跑久后CMA 成功率下降”的常见根因之一。驱动如何使用通过 DMA API 间接接入大多数驱动不直接调用底层 CMA 内部接口而是通过 DMA API分配dma_alloc_coherent()在“设备约束 平台实现”满足时可能走到 CMA 路径释放dma_free_coherent()这样做的好处屏蔽架构差异减少驱动层耦合。更容易与 IOMMU、缓存一致性策略协同。内核升级后驱动层 API 稳定性更好。边界提醒若平台存在 IOMMU驱动常可使用离散物理页并映射为连续 IOVAdma_alloc_coherent()不一定需要 CMA。若设备或平台要求物理连续且无等价后备路径CMA 重要性会显著提升。工程上应先确认 SoC 与内核 DMA 实现再判断“是否依赖 CMA”。一次分配请求的代码路径直觉便于跟源码dma_alloc_coherent() - dma_direct_alloc() / dma-iommu 路径依架构与配置 - 若可用 IOMMU 离散页映射可满足可能不依赖 CMA - 若需要物理连续后备 - dma_contiguous_alloc() - cma_alloc() - alloc_contig_range()关键连续页整理与迁移步骤说明不同内核版本与 SoC 厂商补丁会调整实际调用链排查时应以目标内核源码为准。IOMMU 与 CMA 关系选型判定流程判断“项目是否强依赖 CMA”可以按下图走一遍否是否是否是否是设备发起DMA内存需求平台是否启用IOMMU设备是否要求物理连续通常需要CMA或静态carveout可用普通页分配路径设备或驱动是否必须物理连续优先考虑离散页 IOVA映射仍需CMA或专用预留分配成功率是否稳定关注IOMMU映射开销与TLB行为调容量/查不可迁移页/评估carveout进入常规监控与容量治理落地建议先判设备约束不要先入为主认为“有 IOMMU 就不需要 CMA”或“用 DMA API 就必走 CMA”。再判系统目标若关注极致确定性延迟可能需要在 CMA 与 carveout 之间权衡。最后看实测数据以分配成功率、尾延迟和失败日志为准不靠经验拍脑袋。典型 SoC 场景对照表选型速查场景IOMMU 状态设备 DMA 连续性需求对 CMA 依赖度常见策略MCU/轻量 SoC常见无 IOMMU无常要求物理连续高优先 CMA对关键固定缓冲可评估 carveoutARM64 多媒体 SoC带 SMMU有视频/显示链路中部分模块仍要求物理连续中高常见“CMA IOMMU”混合通用走 IOVA特定链路走 CMA通用服务器/PC 平台有多数外设不强制物理连续低到中以 IOMMU 映射为主按需保留小规模 CMA高实时/低抖动专用设备视平台而定常对时延确定性敏感中到高在 CMA 与 carveout 间做确定性优先权衡结合压测定版使用方法先按“平台类别”找到最接近行再用真实设备约束修正。若同一系统中设备诉求差异大优先采用“分链路策略”避免全系统一刀切。配置实践启动参数与设备树1) 启动参数方式示例cma256Mcma256M3G-4G适合快速试验和单板调参缺点是表达力相对有限。2) 设备树方式推荐长期维护典型关键属性compatible shared-dma-poolreusablelinux,cma-default抽象示例reserved-memory { #address-cells 2; #size-cells 2; ranges; linux,cma { compatible shared-dma-pool; reusable; size 0x0 0x10000000; /* 256MB */ linux,cma-default; }; };调试与可观测性debugfs、meminfo、dmesg调试开关CONFIG_CMA_DEBUGCONFIG_CMA_DEBUGFS常看位置/sys/kernel/debug/cma//sys/kernel/debug/contiguous/部分内核/补丁集可能使用此路径/proc/meminfo重点关注CmaTotal、CmaFreedmesg迁移失败、不可迁移页、分配失败上下文debugfs 实操手术刀式检查# 1) 查看 CMA 区域列表ls/sys/kernel/debug/cma/# 2) 查看指定区域核心状态以 cma-0 为例cat/sys/kernel/debug/cma/cma-0/base_pfncat/sys/kernel/debug/cma/cma-0/countcat/sys/kernel/debug/cma/cma-0/usedcat/sys/kernel/debug/cma/cma-0/bitmap# 3) 分配/释放测试页用于验证区域可用性echo1024/sys/kernel/debug/cma/cma-0/allocecho0/sys/kernel/debug/cma/cma-0/alloc说明不同内核版本 debugfs 节点名称可能不同请以当前系统实际目录为准。建议先做目录探测ls/sys/kernel/debug/cma/2/dev/nullls/sys/kernel/debug/contiguous/2/dev/null关注指标指标说明异常信号CmaFree/CmaTotal比例余量水平长期偏低且波动大单次大块分配成功率服务稳定性高峰时骤降迁移耗时抖动来源尾延迟上升分配失败日志频率故障趋势持续增长常见故障与排障清单现象可能原因排查建议常用动作明明空闲内存很多连续分配仍失败外部碎片严重看CmaFree、位图状态、失败日志触发内存规整并复测CmaFree充足但仍失败页面不可迁移pin/lock看dmesg迁移失败原因排查长期 pin 页来源高峰期偶发卡顿迁移开销高观察分配延迟与迁移耗时调整 CMA 容量与业务峰值错峰启动后设备持续申请失败配置不生效或区域冲突校验 cmdline / DTS 生效情况统一单一来源配置并重启验证可选排障动作按环境谨慎使用# 查看 CMA 总量与空闲cat/proc/meminfo|rgCmaTotal|CmaFree# 触发内存规整echo1/proc/sys/vm/compact_memory# 查看内核日志中的 CMA 相关信息dmesg|rg-icma|dma|migrate|isolate# 增强过滤定位连续页整理/迁移失败线索dmesg|rg-icma|migrate|isolate|alloc_contig风险提示compact_memory是全局规整动作可能带来瞬时延迟抖动Latency Spike。仅建议在压测/诊断窗口或明确可控的维护时段使用不建议作为线上常态化定时脚本。典型“看得见、搬不走”根因清单get_user_pages*()长期 pin 用户页。驱动执行dma_map_*()后未及时dma_unmap_*()。GPU/AI 等设备驱动对页长期持有导致迁移窗口不足。一句话CMA 最怕的不是内存少而是“看得见、迁不走”的页。容量规划与工程建议容量估算思路CMA容量 峰值并发设备需求 安全水位 迁移损耗余量建议结合业务场景做分层预算摄像头链路分辨率、路数、缓冲深度编解码链路输入/输出缓冲与并发转码显示链路多层合成与双/三缓冲示例便于快速估算4 路 1080P 视频每路 3 个 buffer单 buffer 约 2MB基础需求约4 × 3 × 2MB 24MB再加 30% 安全余量与迁移损耗CMA 可先按32MB - 40MB量级起步压测工程建议先从“可观测”开始再谈调参没有指标的容量调优基本不可复现。保持配置单一真源避免 cmdline 与 DTS 同时改、相互覆盖。对关键驱动做失败降级路径分配失败要可恢复不要直接把系统拖死。压测要覆盖“长时间运行后”的碎片化阶段而不仅是冷启动短测。一页速查表值班版问题一句话回答CMA 是什么用“可复用预留区 迁移腾挪”提高连续物理内存分配成功率的机制为什么不是纯静态预留纯预留利用率低CMA 允许闲时复用为什么会失败空间不足只是其一更常见是不可迁移页导致腾挪失败驱动怎么用优先走dma_alloc_coherent/dma_free_coherent先看哪些指标CmaTotal/CmaFree、分配失败日志、迁移耗时典型救火动作校验配置生效、触发规整、定位 pin/locked 页来源总结CMA 的核心不在“预留一块内存”这件事本身而在于它把连续性保障和内存利用率做了工程化折中闲时可复用避免大块内存长期空置。忙时靠迁移腾挪尽可能交付连续块。失败可观测、可排障、可规划。对内核/驱动工程来说真正决定效果的是三件事配置是否正确、页面是否可迁移、指标是否持续可见。免责声明本文面向 Linux 内核与驱动工程实践。不同内核版本、发行版补丁、SoC 内存架构与驱动实现会导致行为差异具体结论请以目标系统源码、配置与实测结果为准。本文基于通用内核实现抽象若目标环境包含 SoC 厂商定制补丁vendor patch或特殊 CONFIG 组合请优先对照实际源码路径与日志行为。延伸阅读Linux kernel docs: CMA (Contiguous Memory Allocator)Linux kernel docs: DMA APILinux kernel docs: Memory compactionLinux man-pages: proc(5)
Linux内核CMA机制详解 连续内存分配原理配置与排障实践
Linux内核CMA机制详解_连续内存分配原理配置与排障实践围绕 Linux 内核中的 CMAContiguous Memory Allocator连续内存分配器系统讲清楚它为什么存在、如何与伙伴系统协同、迁移与隔离的关键路径、驱动侧使用方式、配置方法、调试观察点和线上排障步骤。目录先回答核心问题为什么还需要 CMACMA 的设计目标与边界工作原理总览预留、复用、迁移、分配关键数据结构struct cma与位图模型初始化路径与启动阶段行为迁移路径中的核心概念MIGRATE_CMA与MIGRATE_ISOLATE驱动如何使用通过 DMA API 间接接入IOMMU 与 CMA 关系选型判定流程配置实践启动参数与设备树调试与可观测性debugfs、meminfo、dmesg常见故障与排障清单容量规划与工程建议一页速查表值班版总结免责声明延伸阅读先回答核心问题为什么还需要 CMADMA 设备摄像头、显示、编解码、AI 加速器等常要求物理连续内存。系统运行一段时间后即使“总空闲内存很多”也可能因为外部碎片无法拿到足够大的连续块。这正是 CMA 的价值它不是“只会浪费内存的静态预留”而是通过可复用预留区 需要时迁移腾挪在“利用率”和“连续性保证”之间做平衡。机制对连续内存保障对总体内存利用率纯静态 carveout高低闲时难复用纯伙伴系统低碎片化后不稳定高CMA中高依赖可迁移性中高CMA 的设计目标与边界设计目标为设备提供较稳定的大块连续物理页分配能力。在设备未占用时允许该区域被系统暂时复用。分配失败时提供可观测、可定位的排障路径。能力边界CMA 不是“任何时候都 100% 成功”的承诺其成功率依赖页面可迁移性。被长期 pin、locked 或不可迁移的页会直接影响分配结果。实时性和大块成功率依赖容量规划与负载模型不能只靠默认配置。dma_alloc_coherent()并不等于“必走 CMA”是否落到 CMA 与平台内存拓扑、DMA 约束、IOMMU/IOVA 路径和内核配置有关在有 IOMMU 的系统中很多设备可通过离散物理页映射到连续 IOVA未必依赖 CMA 提供物理连续块。工作原理总览预留、复用、迁移、分配区域足够空闲被占用启动阶段预留CMA区域标记为MIGRATE_CMA闲时可被普通分配复用设备请求连续内存直接分配隔离目标pageblockMIGRATE_ISOLATE迁移可迁移页到其他位置腾出连续空间设备DMA使用释放后回归CMA位图管理可以把它理解为先圈一块“可弹性借用”的连续内存候选区需要时通过迁移把“临时住户”搬走再把连续空间交给设备。关键数据结构struct cma与位图模型CMA 区域通常由struct cma这类结构描述核心字段常包括可结合 CMA debugfs 文档 对照理解字段含义工程意义base_pfn区域起始页帧号对应物理起点count区域总页数对应总容量bitmap分配状态位图快速查找连续空闲片段order_per_bit每 bit 对应页数2^n位图粒度与扫描效率权衡位图抽象0空闲可用。1已占用。位图本身并不解决碎片只是状态管理工具真正“腾连续块”的关键仍在页面迁移能力。初始化路径与启动阶段行为常见路径可抽象为start_kernel()-setup_arch()- 预留与登记 CMA 区域 - 初始化位图与迁移类型来源通常有两类内核启动参数如cma256M3G-4G。设备树reserved-memory节点。初始化完成后这些区域会进入 CMA 管理并与伙伴系统形成“可复用、可回收”的协同关系。迁移路径中的核心概念MIGRATE_CMA与MIGRATE_ISOLATE当设备申请连续块而目标片段已被占用时通常会发生下面流程将目标 pageblock 从MIGRATE_CMA切到MIGRATE_ISOLATE阻止新的干扰分配进入。对当前占用页执行迁移前提是页可迁移。连续区间腾空后完成分配。完成后恢复 pageblock 的迁移类型回到 CMA 常态。这个流程的本质是“先封控、再迁移、后交付、再恢复”。一句话记忆CMA 不是“天然永远连续”而是“在 pageblock 粒度通过迁移类型切换来尽量恢复连续性”。补充理解工程常见误区pageblock 是内存迁移与分配策略的重要粒度单元具体大小与内核配置相关。如果 pageblock 长期混入不可迁移页面例如 unmovable/pinned这块区域可用性会持续变差。这也是“系统跑久后CMA 成功率下降”的常见根因之一。驱动如何使用通过 DMA API 间接接入大多数驱动不直接调用底层 CMA 内部接口而是通过 DMA API分配dma_alloc_coherent()在“设备约束 平台实现”满足时可能走到 CMA 路径释放dma_free_coherent()这样做的好处屏蔽架构差异减少驱动层耦合。更容易与 IOMMU、缓存一致性策略协同。内核升级后驱动层 API 稳定性更好。边界提醒若平台存在 IOMMU驱动常可使用离散物理页并映射为连续 IOVAdma_alloc_coherent()不一定需要 CMA。若设备或平台要求物理连续且无等价后备路径CMA 重要性会显著提升。工程上应先确认 SoC 与内核 DMA 实现再判断“是否依赖 CMA”。一次分配请求的代码路径直觉便于跟源码dma_alloc_coherent() - dma_direct_alloc() / dma-iommu 路径依架构与配置 - 若可用 IOMMU 离散页映射可满足可能不依赖 CMA - 若需要物理连续后备 - dma_contiguous_alloc() - cma_alloc() - alloc_contig_range()关键连续页整理与迁移步骤说明不同内核版本与 SoC 厂商补丁会调整实际调用链排查时应以目标内核源码为准。IOMMU 与 CMA 关系选型判定流程判断“项目是否强依赖 CMA”可以按下图走一遍否是否是否是否是设备发起DMA内存需求平台是否启用IOMMU设备是否要求物理连续通常需要CMA或静态carveout可用普通页分配路径设备或驱动是否必须物理连续优先考虑离散页 IOVA映射仍需CMA或专用预留分配成功率是否稳定关注IOMMU映射开销与TLB行为调容量/查不可迁移页/评估carveout进入常规监控与容量治理落地建议先判设备约束不要先入为主认为“有 IOMMU 就不需要 CMA”或“用 DMA API 就必走 CMA”。再判系统目标若关注极致确定性延迟可能需要在 CMA 与 carveout 之间权衡。最后看实测数据以分配成功率、尾延迟和失败日志为准不靠经验拍脑袋。典型 SoC 场景对照表选型速查场景IOMMU 状态设备 DMA 连续性需求对 CMA 依赖度常见策略MCU/轻量 SoC常见无 IOMMU无常要求物理连续高优先 CMA对关键固定缓冲可评估 carveoutARM64 多媒体 SoC带 SMMU有视频/显示链路中部分模块仍要求物理连续中高常见“CMA IOMMU”混合通用走 IOVA特定链路走 CMA通用服务器/PC 平台有多数外设不强制物理连续低到中以 IOMMU 映射为主按需保留小规模 CMA高实时/低抖动专用设备视平台而定常对时延确定性敏感中到高在 CMA 与 carveout 间做确定性优先权衡结合压测定版使用方法先按“平台类别”找到最接近行再用真实设备约束修正。若同一系统中设备诉求差异大优先采用“分链路策略”避免全系统一刀切。配置实践启动参数与设备树1) 启动参数方式示例cma256Mcma256M3G-4G适合快速试验和单板调参缺点是表达力相对有限。2) 设备树方式推荐长期维护典型关键属性compatible shared-dma-poolreusablelinux,cma-default抽象示例reserved-memory { #address-cells 2; #size-cells 2; ranges; linux,cma { compatible shared-dma-pool; reusable; size 0x0 0x10000000; /* 256MB */ linux,cma-default; }; };调试与可观测性debugfs、meminfo、dmesg调试开关CONFIG_CMA_DEBUGCONFIG_CMA_DEBUGFS常看位置/sys/kernel/debug/cma//sys/kernel/debug/contiguous/部分内核/补丁集可能使用此路径/proc/meminfo重点关注CmaTotal、CmaFreedmesg迁移失败、不可迁移页、分配失败上下文debugfs 实操手术刀式检查# 1) 查看 CMA 区域列表ls/sys/kernel/debug/cma/# 2) 查看指定区域核心状态以 cma-0 为例cat/sys/kernel/debug/cma/cma-0/base_pfncat/sys/kernel/debug/cma/cma-0/countcat/sys/kernel/debug/cma/cma-0/usedcat/sys/kernel/debug/cma/cma-0/bitmap# 3) 分配/释放测试页用于验证区域可用性echo1024/sys/kernel/debug/cma/cma-0/allocecho0/sys/kernel/debug/cma/cma-0/alloc说明不同内核版本 debugfs 节点名称可能不同请以当前系统实际目录为准。建议先做目录探测ls/sys/kernel/debug/cma/2/dev/nullls/sys/kernel/debug/contiguous/2/dev/null关注指标指标说明异常信号CmaFree/CmaTotal比例余量水平长期偏低且波动大单次大块分配成功率服务稳定性高峰时骤降迁移耗时抖动来源尾延迟上升分配失败日志频率故障趋势持续增长常见故障与排障清单现象可能原因排查建议常用动作明明空闲内存很多连续分配仍失败外部碎片严重看CmaFree、位图状态、失败日志触发内存规整并复测CmaFree充足但仍失败页面不可迁移pin/lock看dmesg迁移失败原因排查长期 pin 页来源高峰期偶发卡顿迁移开销高观察分配延迟与迁移耗时调整 CMA 容量与业务峰值错峰启动后设备持续申请失败配置不生效或区域冲突校验 cmdline / DTS 生效情况统一单一来源配置并重启验证可选排障动作按环境谨慎使用# 查看 CMA 总量与空闲cat/proc/meminfo|rgCmaTotal|CmaFree# 触发内存规整echo1/proc/sys/vm/compact_memory# 查看内核日志中的 CMA 相关信息dmesg|rg-icma|dma|migrate|isolate# 增强过滤定位连续页整理/迁移失败线索dmesg|rg-icma|migrate|isolate|alloc_contig风险提示compact_memory是全局规整动作可能带来瞬时延迟抖动Latency Spike。仅建议在压测/诊断窗口或明确可控的维护时段使用不建议作为线上常态化定时脚本。典型“看得见、搬不走”根因清单get_user_pages*()长期 pin 用户页。驱动执行dma_map_*()后未及时dma_unmap_*()。GPU/AI 等设备驱动对页长期持有导致迁移窗口不足。一句话CMA 最怕的不是内存少而是“看得见、迁不走”的页。容量规划与工程建议容量估算思路CMA容量 峰值并发设备需求 安全水位 迁移损耗余量建议结合业务场景做分层预算摄像头链路分辨率、路数、缓冲深度编解码链路输入/输出缓冲与并发转码显示链路多层合成与双/三缓冲示例便于快速估算4 路 1080P 视频每路 3 个 buffer单 buffer 约 2MB基础需求约4 × 3 × 2MB 24MB再加 30% 安全余量与迁移损耗CMA 可先按32MB - 40MB量级起步压测工程建议先从“可观测”开始再谈调参没有指标的容量调优基本不可复现。保持配置单一真源避免 cmdline 与 DTS 同时改、相互覆盖。对关键驱动做失败降级路径分配失败要可恢复不要直接把系统拖死。压测要覆盖“长时间运行后”的碎片化阶段而不仅是冷启动短测。一页速查表值班版问题一句话回答CMA 是什么用“可复用预留区 迁移腾挪”提高连续物理内存分配成功率的机制为什么不是纯静态预留纯预留利用率低CMA 允许闲时复用为什么会失败空间不足只是其一更常见是不可迁移页导致腾挪失败驱动怎么用优先走dma_alloc_coherent/dma_free_coherent先看哪些指标CmaTotal/CmaFree、分配失败日志、迁移耗时典型救火动作校验配置生效、触发规整、定位 pin/locked 页来源总结CMA 的核心不在“预留一块内存”这件事本身而在于它把连续性保障和内存利用率做了工程化折中闲时可复用避免大块内存长期空置。忙时靠迁移腾挪尽可能交付连续块。失败可观测、可排障、可规划。对内核/驱动工程来说真正决定效果的是三件事配置是否正确、页面是否可迁移、指标是否持续可见。免责声明本文面向 Linux 内核与驱动工程实践。不同内核版本、发行版补丁、SoC 内存架构与驱动实现会导致行为差异具体结论请以目标系统源码、配置与实测结果为准。本文基于通用内核实现抽象若目标环境包含 SoC 厂商定制补丁vendor patch或特殊 CONFIG 组合请优先对照实际源码路径与日志行为。延伸阅读Linux kernel docs: CMA (Contiguous Memory Allocator)Linux kernel docs: DMA APILinux kernel docs: Memory compactionLinux man-pages: proc(5)
