Android Display性能问题教战手册5-SF/HWC内存使用问题

Dwyane03

已于 2024-09-23 16:24:17 修改

阅读量1.1k

点赞数 24

分类专栏： Android智能座舱文章标签： android

于 2024-09-23 16:23:42 首次发布

本文链接：https://blog.csdn.net/oDwyane03/article/details/142461501

版权

Android智能座舱专栏收录该内容

17 篇文章 0 订阅

订阅专栏

系列文章请扫关注公众号！

Android Display Graphics系列文章-汇总

本文主要包括部分：

1、dma-buf问题初步判定方法

2、SF/HWC dma-buf debug

3、SF/HWC与对比机内存使用对比问题

本文主要分析SurfaceFlinger、Hardware composer内存使用问题，及dma-buf的debug技巧。

Overview

dma-buf是一个多进程间的buffer共享的机制，本节主要介绍针对display部分相关的dma-buf如何做初步的分析

在Android中Buffer需要在多个进程间传递使用的Module有很多，但用量比较明显，无法回避的主要都在MM相关module中，其中显示Graphic图形使用的Buffer是最为频繁的， Buffer会在APP / sytemserver / Surface / GPU / SurfaceFlinger / hwcomposer / kernel display DRM driver 等module间进行传递使用，所以Graphic的相关Module是最容易被Call到需要来厘清dma-buf使用情况的

1、dma-buf问题初步判定方法

怎样判定当前的内存问题是dma-buf相关的问题呢？

在meminfo中的 EGL mtrack 部分就是代表 dma buf的用量，如果这部分用量异常则需要厘清dma buf的使用情况

dma-buf使用异常会与哪些问题相关？

1，内存分配不出引发的异常：各种exception, 图像卡死等现象，伴有低内存的，经过内存owner分析以后无其他内存异常的

2, 内存占用异常：主要指在一些预期不会使用很多内存的场景，出现较大的dma-buf占用

3, buffer相关fd异常：目前对于fd主要会报异常的就是fdsan，或者有些exception发生前突然出现fd error等

发生异常时如何进一步查看dma-buf的使用信息呢？

1， 有发生exception，且能获取到db的情况：

Hang : SYS_DMA_HEAP_RAW

SWT/Other: DMABUF_HEAP_INFO / ION_DMABUF_SYSTEM_INFO

OOM/KE/JE：SYS_KERNEL_LOG(search keyword: "dma_heap: mtk_debug")

2, 没有发生exception或没有db的情况：

此种情况一般基本要求是device保有内存使用异常的现场未恢复，进阶要求是有找到一些复现操作路径，并且可以观察到EGL mtrack部分随着使用在持续增长且不会自动减少

制作adb脚本去循环cat meminfo，并持续比较和观察EGL mtrack部分，可以设定增长到一定Size即主动去kill -11 [SurfaceFlinger Pid] 来产生NE, 以固定到问题现场并提取到db

如果不方便触发和提取到db，可以通过以下cmd去cat到当前一些dmabuf的info出来

adb shell cat /proc/dma_heap/all_heaps > all_dma_heaps.txt 此文件为MTK平台独有，在MTK平台debug时推荐优先查看

adb shell /system/bin/dma_buf_dump > dmabuf_dump.txt 此文件会按进程分开列出每个进程的dma buf持有情况

adb shell dmabuf_dump -a > dmabuf_dump_a.txt 该文件为Android默认节点，其列表形式比较容易查看Fd ref/ Map ref count持有情况

adb shell dmabuf_dump -b > dmabuf_dump_b.txt 该文件为Android默认节点，主要时按per buffer进行统计汇总

2、SF/HWC dma-buf debug

SF/HWC作为图形系统的传递中枢， Buffer的使用异常通常都会有surfaceflinger和composer的中间持有，这也是此类问题为什么会常常需要SF/HWC owner参与梳理的原因

SF/HWC的梳理step by step:

1, 首先通过all_dma_heaps可以观察整体状况

此处dump首先会列出dma buffer的主要user, 我们主要关注surfaceflinger和composer的使用量是否有异常

PID PSS(KB) RSS(KB)

3236 25272 47712

2935 103267 127272

1443 37533 108432

1225 4 4

984 102401 371176

906 232617 330476

893 48 48

-----EGL memtrack data end

--sum: userspace_pss:501143 KB rss:985120 KB

--sum: kernel rss: 3136 KB

pid table:

pid:3236 name:droid.launcher3

pid:2935 name:ndroid.systemui

pid:1443 name:system_server

pid:1225 name:binder:1225_2

pid:984 name:surfaceflinger

pid:906 name:composer@3.2-se

pid:893 name:binder:893_2

同步观察dump中列出的top 10用量的buffer, 注意这里把 buffer name 都有打印出来, 因为Buffer最终通过BufferQueue分配使用，所以其使用进程肯定会经过surfaceflinger和composer，此处可以进一步分辨是否有哪个名字的buffer使用量过多，需要进一步去分析关注

dmabuf alloc total:(361/504280KB), top 10 user:
debug name sum of size(KB) count of heap
G:ColorFade#2(BLAST Consumer)2 79772 37
G:VRI[NotificationShade]#13(BLA 79772 13
G:VRI[GalleryActivity]#4(BLAST 77840 37
G:SurfaceView[com.android.galle 73500 37
FramebufferSurface 63552 37
G:screenshot 44880 12
G:ColorFade#3(BLAST Consumer)3 31444 35
G:VRI[]#14(BLAST Consumer)14 29092 10
G:Wallpaper#0(BLAST Consumer)0 11316 9
G:VRI[NavigationBar0]#1(BLAST C 4368 64

2，去具体查看有嫌疑的Buffer的使用情况

3，进一步debug ref count不归 0 的原因

( i ) SF/APP

（ii）HWC

（iii）kernel

3、SF/HWC与对比机内存使用对比问题

SF部分主要差异就是在Buffer数量上，主要分为两点：.......

Composer进程的差异：........

=========================================================================

============================完整文章见公众号===============================

=========================================================================