T33-自动化测试反复跑 test 触发 OOM：ISP bin 内存改 vmalloc 并缩减分配大小

适用场景

        在 T32Pro（及同类平台）做自动化测试、反复轮询 test 程序时，出现 OOM 内存错误，且摄数越多越明显。本文适用于排查这类「重复运行导致的累计/分配内存不足」问题，重点是 ISP bin 文件的内存分配方式与大小。

问题现象

        T32Pro 跑自动化测试反复轮询 test 程序报 OOM，双摄、三摄、四摄均出现。关键对照：相同双摄 500W 配置下 T32-NQ 正常，仅 T32Pro 报 OOM；test 之间加延时后概率缓解但未解决，重复跑同一个 test 即可复现。

根因分析

        OOM 的根因是 ISP bin 文件内存使用 kmalloc 分配，且默认分配偏大：

    • kmalloc 分配的是连续物理内存，分配大块时更容易因内存碎片化失败；

    • bin 默认分配较大，在自动化测试反复加载 bin 的场景下，物理连续内存被反复占用，最终触发 OOM。

    「加延时概率缓解」说明与重复分配/释放的时序相关，但根因在分配方式与大小，延时只是降低复现概率。

排查与修复方法

    第一步，确认对照关系。用同配置在小内存压力或不同芯片（T32-NQ vs T32Pro）上对比，锁定是平台/分配路径差异。

    第二步，定位 ISP bin 的内存分配。确认 bin 解析加载时用 kmalloc 还是 vmalloc、分配大小是多少。

    第三步，改为 vmalloc。vmalloc 分配虚拟连续（物理可不连续）内存，对大块分配更友好，降低 OOM 风险。

    第四步，缩减分配大小。将 bin 分配由 400 缩减为 200（K），并同步修改 SDK 侧 mmap，保证驱动与 SDK 一致。

    第五步，压测验证。反复运行 test，确认不再 OOM；并对大分辨率 sensor（如 800 万）回归，确认缩减后无副作用。

验证结果

        修改后测试数天有效，代码（SDK + ISP）已入库，T32Pro 与 CW080 同步修改，后续数日测试 ok。

使用建议

        排查自动化测试反复运行导致的 OOM，优先检查大块内存的分配方式（kmalloc 的物理连续限制）与分配大小是否可优化；改 vmalloc + 缩减分配是常见有效手段，但需回归大分辨率场景确认无副作用。