我来帮你拆解这个问题——结合你的定制IMX板（512MB内存）的OOM日志，还有ARM架构Linux的内存管理特性，缺失Normal free....行主要是这几个原因：

1. 内存区域命名和架构特性不匹配 #

IMX属于ARM架构，内核里的内存区域划分和x86平台不一样：你的日志里明确输出了Node 0 DMA32区域的完整内存统计：

Oct 06 05:20:08 IMX kernel: Node 0 DMA32 free:125904kB min:7028kB low:7568kB high:8108kB active_anon:91884kB inactive_anon:848kB active_file:1484kB inactive_file:1800kB unevictable:90444kB writepending:>

在ARM平台上，很多场景下所有可通用的内存都会被归类到DMA32区域（支持32位DMA访问的内存），而不会像x86那样划分出单独的Normal区域。你预期的Normal free....行，其实就是这里的Node 0 DMA32 free:...，只是内存区域的命名不同而已。

从日志的总内存统计也能验证这一点：总RAM是122880 pages，换算成KB是122880 * 4 = 491520KB（约480MB），和你说的512MB接近，剩下的内存被内核预留（10212 pages reserved）和CMA区域占用了。

2. CMA区域占用了大量空闲内存 #

日志里有个关键数据：free_cma:30052（对应30052 *4KB=120208KB），而Node 0 DMA32 free:125904kB。这说明大部分空闲内存被CMA（连续内存分配器）预留了——CMA是专门给硬件驱动提供连续物理内存的特殊区域，它的空闲内存不会被算到普通的"Normal"空闲统计里，而是单独标注。如果你的内核把CMA和DMA32区域合并统计，自然不会出现单独的Normal行。

3. 内核版本导致的日志格式差异 #

不同Linux内核版本的OOM日志输出格式有明显区别：较新的内核会按内存节点（Node）和区域（Zone）输出更细粒度的统计，替代了旧版本里笼统的Normal free....表述。你的日志已经完整输出了DMA32区域的空闲、活跃内存等数据，这其实是更详细的内存状态信息，没必要再单独输出Normal行。

额外补充：你的OOM触发逻辑 #

从OOM的核心日志来看：

Oct 06 05:20:08 IMX kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/rotomac.service,task=rotomac,pid=949,uid=0
Oct 06 05:20:08 IMX kernel: Out of memory: Killed process 949 (rotomac) total-vm:801480kB, anon-rss:83376kB, file-rss:5468kB, shmem-rss:4kB, UID:0 pgtables:352kB oom_score_adj:0

被杀死的rotomac进程占用了约83MB的匿名内存，加上其他进程的内存占用，导致DMA32区域的空闲内存低于内核的min阈值（7028kB），触发了全局OOM。这里的内存状态已经通过DMA32区域的统计完全体现，不需要额外的Normal行。

内容的提问来源于stack exchange，提问作者preetam