Speakers
Description
Problem Statement
Android UI rendering is latency-sensitive — at 90Hz, each frame has only ~11ms time budget. When a UI-critical thread (e.g., RenderThread) is blocked in the kernel, the frame is likely to be dropped.
We profiled 40 popular Android applications on a Pixel 6 (kernel 6.18.0-mainline, 90Hz refresh rate), using ftrace lock_contention events correlated with Perfetto FrameTimeline data, to confirm causal links between lock contention and dropped frames.
The results show that approximately 14% of all dropped frames are causally attributable to kernel lock contention. The contention concentrates in 5 subsystems that account for over 90% of all lock-caused frame drops.
We would like to present these findings and discuss optimization directions with the community.
Top 5 Problems
1. Mali GPU Driver
The Mali GPU kernel driver uses multiple locks in its internal paths such as job submission and scheduling, and the RenderThread is observed to be occasionally blocked on these locks, causing frame drops.
To discuss: What optimization approaches are available for reducing lock contention in the Mali GPU driver? Is this a known issue?
2. mmap_lock
Several mm paths contend on the same per-process mmap_lock on both write side (e.g., mmap, mprotect) and read side (page faults).
RFC PATCH: https://lore.kernel.org/lkml/20260804095135.45897-1-zhanghongru@xiaomi.com/
To discuss: We have frame-drop causation data showing mmap_lock contention still impacts Android UI performance on 6.18. How effective are current mitigations in practice? What remains to be addressed?
3. ZRAM Compression
We observed priority inversion in the ZRAM swap-in path with durations exceeding 20ms. Threads such as RenderThread, Bluetooth, and SystemUI are observed to be blocked on this lock.
RFC PATCH: https://lore.kernel.org/all/20260805005545.66112-1-baohua@kernel.org/
To discuss: Possible approaches to avoid priority inversion in the ZRAM swap-in path
4. Binder IPC Allocator
We observed lock contention in the Binder buffer allocation path with durations exceeding 8ms. Threads such as RenderThread, SystemUI, and app main threads are observed to be blocked on this lock.
RFC PATCH: https://lore.kernel.org/all/20260805152752.1924434-1-zhangbo56@xiaomi.com/
To discuss: Is this a known issue? What approaches can reduce lock contention in the Binder allocation path?
5. cgroup threadgroup rwsem
We observed lock contention in the process fork and exit paths (cgroup_threadgroup_rwsem) with durations exceeding 11ms. The RenderThread is observed to be blocked on this lock.
To discuss: Is this a known issue? What approaches can reduce lock contention on cgroup_threadgroup_rwsem?