Physical memory黑屏现象

前段时间在做播放器的时候，遇到个问题，花了很长时间，做个记录，希望对有需要的人有所帮助：

播放器的播视频的时候，无论是手动切换视频还是到视频播放完成，自动切换视频，一定次数后均出现黑屏现象，偶尔有声音，问题出现后，不可恢复，Kernel输出如下Log：

DMA free:71672kB min:616kB low:768kB high:924kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolateds

lowmem_reserve[]: 0 1244 1593 1593

Normal free:1249804kB min:4212kB low:5264kB high:6316kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB o

lowmem_reserve[]: 0 0 2794 2794

HighMem free:223000kB min:348kB low:640kB high:936kB active_anon:39248kB inactive_anon:140kB active_file:61020kB inactive_file:34108kB unevio

lowmem_reserve[]: 0 0 0 0

DMA: 224kB 908kB 2116kB 8232kB 764kB 137128kB 69256kB 3512kB 81024kB 52048kB 34096kB 08192kB 016384kB 032768kB = 71672kB

Normal: 14kB 538kB 1616kB 632kB 664kB 4128kB 1256kB 1512kB 21024kB 22048kB 34096kB 28192kB 416384kB 3532768kB = 1249772kB

HighMem: 144kB 108kB 43716kB 38632kB 37464kB 27128kB 10256kB 7512kB 81024kB 72048kB 44096kB 28192kB 116384kB 332768kB = 223000B

23829 total pagecache pages

0 pages in swap cache

Swap cache stats: add 0, delete 0, find 0/0

Free swap = 0kB

Total swap = 0kB

524288 pages of RAM

387015 free pages

73287 reserved pages

1169 slab pages

8545 pages shared

0 pages swap cached

Physical memory allocation error!

Physical memory allocation error!

通过Log，定位到输出的位置是解码驱动中，驱动在DMA请求失败后，输出以上信息。针对这个现象，按以下几个思路进行的调查：

1. 内存泄露

在驱动中增加了一些Log，随着视频切换，分配的地址会一定程度的变大，直到最后分配失败。但仔细研究发现分配与释放是配对的，驱动中记录的内存使用信息完全正确，没有任何迹象表明有内存泄露发生。

2. 内存碎片

官论上有同样的问题登录，但无明确结论，官方应该是没重现。民间有人指出问题在于驱动请求的连续内存块比较大，但系统已无相应的内存可供分配，即内存碎片了。同时有人给出俩个方案：缓存每次的请求的内存，分配后，不再返还给系统，这个方案我测试后，发现会导致其它视频驱动出现同样问题，不可用；另一个方案是认为导致内存碎片的原因在于，文件系统的Cache机制，要解决这个问题，需要清除被Cache占用的内存，方法如下：

echo 3 > /proc/sys/vm/drop_caches

试验之后，果然有效，测试了手中的测试用例几千次后，发了测试软件，结果悲剧，开发部的测试用例几次就测出同样的问题，该方案水土不服。

3. 调查Linux内存使用

从内存碎片这个思路出发，分析什么导致了驱动的DMA空间碎片化。查了一些资料发现，Linux的内存划分分成3块：DMA，Low Memory和High Memory。一般32位PC的配置是DMA Zone位于0x00010000-0x00ffffff，大约16MB，Low Memory是0x01000000-0x37bfdfff，约800多MB，再往上的空间给High Memory，这部分的访问要通过跳转，性能不如DMA Zone和Low Memory Zone快。而内存分配的策略是从上往下分配，一旦高位的内存空间不足，则向低地址的空间请求内存。在我们的产品上，总的内存大小是512MB，某些驱动预留128MB，DMA Zone的配置是184MB，那么实际剩下的Low Memory Zone只有200MB，而这200MB要运行UI，媒体管理，互联等等一系列进程。一旦Low Memory Zone的内存不够用，系统会向DMA Zone请求内存，从而导致的DMA空间的内存碎片化！而这时，通过free命令是看不到正确的内存信息的，因为看到的空间还有，但一是被Cache占用，二是计算的是总数，而不是真正的连续内存，这时查看内存应该使用系统提供的Buddy Info来看真正剩余的内存块：

$cat /proc/buddyinfo

Node 0, zone DMA 3 1 3 4 1 2 2 0 1 2 0 3 2 2

Node 0, zone Normal 74 36 29 8 6 4 3 2 1 2 3 2 0 2

输出的数据从左侧开始是4K内存块的个数，依次乘2到最右侧的32M；在出问题时，系统基本上只有小块的内存，而问题的原因就是一些文件访问的操作导致DMA Zone的空间被Cache使用了。

4. 控制内存分配算法

找到问题的原因后，调查如何能禁止系统从DMA Zone分配内存。查找到可以设置lowmem_reserve_ratio，来告诉系统，DMA Zone的预留空间。其参数有3个（系统默认：256,32,32），与DMA Zone有关的是第一个，其值是除数，用DMA Zone的大小除以256，得到的基本就是预留的大小了。做了几个测试后，发现只有设置为1才能有效保护DMA Zone不被占用，😦!设置为1后，视频不再出现黑屏，但其他问题很快出现，因为系统可用的内存减少，内存的回收算法被频繁执行，性能急剧下降。

5. 最终方案

由于产品的总内存太小，而预留的DMA Zone太大，所以需要调整DMA Zone预留的空间，但lowmem_reserve_ratio已无调整空间，所以考虑从调整Kernel上下手。最后，将Kernel中的DMA Zone总大小由184MB调整为原来的3/4，即138MB，得到一个近似合理的配置，保证的DMA和Low Memory都可以申请到足够的空间，长时间测试后，未再现相关问题。

分类: 嵌入式