yulinchenhades

> 是不是 32 位的程序，4G 的虚地址空间用完了？用 64 位程序试试 不是，uname -m显示是aarch64，在系统上编译的，32位程序的只能用4G内存，我能缓存1000张4k的mppframe，肯定用了10几G了。我解码图片成mppframe的时候都没报错，把mppframe拿出后保存成图片才发现341张后的图片都是绿色。我把这1000张转成1080p，然后用同样的程序去处理，输出的图片就是正常的

> The device iova space is only 4G. So if the dma-buf attach to device is over 4G then it may have error. I will bring kernel guys in to...

> 分 buffer 的时候还好，就是给硬件使用的时候，硬件的 iommu_domain 的 iova 是 32bit 的，不断把 buffer import 到 iommu_domain 之后超上限了 分buffer也没什么效果吧，因为这个mpp buffer group使用量上去之后就一直占用内存，即使把mpp buffer给release也会一直占用内存，所以我分配buffer的时候特地使用mpp_buffer_group_usage判断是否使用了500M，超过了就分个mpp buffer group出来，然后使用mpp_buffer_group_unused检测去释放mpp buffer group，所以即使分buffer，只要buffer总的使用量超过4G，后面分出来的buffer在使用上就会有问题。

> 不是，分 buffer 的时候问题不大，板上有 8G 物理内存，超 4G 不是问题，buffer group 也不影响 是 buffer 在给内核驱动使用的时候，内核里的 iommu 给 buffer 建硬件访问用的 iova 表的时候，这个 iova 地址只有 32bit，总空间只有 4G 单个buffer超过4G肯定是不行的，因为iova的限制。但是我使用的方法是每500M切个buffer，保存mppframe，如果按你说的，应该也没问题，但是为什么只有4G的buffer空间保存的mppframe能解码jpg有效，其他buffer空间保存解码的mppframe最终图片都是绿色的呢

> 因为每次 buffer 导入 map 的时候需要去建 iova 表，建 iova 表的时间太长，为了优化目的，在使用完 buffer 之后不会去把 iova 表释放，就先缓存着，这样导致空间被占用着，一直累积下来，新的 buffer 再导入就失败了。 按这样子其实总的buffer group的使用量还是要限制在4G以内，如果达到4G，新申请的buffer是没办法做iova的，是没效果的。