> BTW We don't have any identification for an attachment, so when multiple > devices attach to the same DMA-buf the trace would be quite meaningless. We > should probably fix that. At present, from the perspective of processes, trace still makes sense.
________________________________ 发件人: 高翔 发送时间: 2025年11月28日 21:14:14 收件人: Christian König; Barry Song; Xiang Gao 抄送: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] 主题: 答复: [External Mail]Re: [PATCH v4] dma-buf: add some tracepoints to debug. > Thinking more about it I was wondering if we really need the userspace > assigned name in the tracepoint in the first place. > The ino should be sufficient to uniquely identify each dma-buf, tracing the > name should only be printed if it's changing or otherwise we spam the > tracelog quite a bit with it. Many threads use dmabuf "qcom,system". If there is a userspace name, we can immediately find the dmabuf I'm using. It might indeed not be necessary in other scenarios. > BTW We don't have any identification for an attachment, so when multiple > devices attach to the same DMA-buf the trace would be quite meaningless. We > should probably fix that. This requires some thought. ________________________________ 发件人: Christian König <[email protected]> 发送时间: 2025年11月28日 17:39:31 收件人: Barry Song; Xiang Gao 抄送: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; 高翔 主题: [External Mail]Re: [PATCH v4] dma-buf: add some tracepoints to debug. [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected]进行反馈 On 11/28/25 10:31, Barry Song wrote: > On Fri, Nov 28, 2025 at 4:53 PM Xiang Gao <[email protected]> wrote: >> >> From: gaoxiang17 <[email protected]> >> >> I want to track the status of dmabuf in real time in the production >> environment. >> But now we can only check it by traversing the fd in the process or >> dmabuf_list. > > might be: > > Since we can only inspect dmabuf by iterating over process FDs or the > dmabuf_list, we need to add our own tracepoints to track its status in > real time in production. > >> >> For example: >> binder:3031_4-18348 [005] ...1. 545.568275: dma_buf_export: >> exp_name=qcom,system name=(null) size=217088 ino=2750 >> binder:3031_4-18348 [005] ...1. 545.568284: dma_buf_fd: >> exp_name=qcom,system name=(null) size=217088 ino=2750 fd=8 >> binder:3031_4-18348 [005] ...1. 545.568399: dma_buf_mmap_internal: >> exp_name=qcom,system name=qcom,system size=28672 ino=2751 >> kworker/5:1-130 [005] ...1. 545.570193: dma_buf_put: >> exp_name=qcom,system name=ab size=28672 ino=2751 >> RenderThread-18891 [005] ...1. 545.602994: dma_buf_get: >> exp_name=qcom,system name=ab size=217088 ino=2750 fd=1087 >> RenderThread-9409 [000] .n.1. 545.745004: dma_buf_dynamic_attach: >> exp_name=qcom,system name=ab size=217088 ino=2750 is_dynamic=0 >> dev_name=kgsl-3d0 >> RenderThread-9409 [005] ...1. 545.747802: dma_buf_detach: >> exp_name=qcom,system name=bq size=12771328 ino=2764 is_dynamic=0 >> dev_name=kgsl-3d0 >> >> Signed-off-by: Xiang Gao <[email protected]> >> --- >> drivers/dma-buf/dma-buf.c | 48 +++++++++- >> include/trace/events/dma_buf.h | 160 +++++++++++++++++++++++++++++++++ >> 2 files changed, 207 insertions(+), 1 deletion(-) >> create mode 100644 include/trace/events/dma_buf.h >> >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >> index 2bcf9ceca997..6e04e12f149e 100644 >> --- a/drivers/dma-buf/dma-buf.c >> +++ b/drivers/dma-buf/dma-buf.c >> @@ -35,6 +35,9 @@ >> >> #include "dma-buf-sysfs-stats.h" >> >> +#define CREATE_TRACE_POINTS >> +#include <trace/events/dma_buf.h> >> + >> static inline int is_dma_buf_file(struct file *); >> >> static DEFINE_MUTEX(dmabuf_list_mutex); >> @@ -220,6 +223,11 @@ static int dma_buf_mmap_internal(struct file *file, >> struct vm_area_struct *vma) >> dmabuf->size >> PAGE_SHIFT) >> return -EINVAL; >> >> + if (trace_dma_buf_mmap_internal_enabled()) { >> + guard(spinlock)(&dmabuf->name_lock); >> + trace_dma_buf_mmap_internal(dmabuf); >> + } >> + >> return dmabuf->ops->mmap(dmabuf, vma); >> } >> >> @@ -745,6 +753,11 @@ struct dma_buf *dma_buf_export(const struct >> dma_buf_export_info *exp_info) >> >> __dma_buf_list_add(dmabuf); >> >> + if (trace_dma_buf_export_enabled()) { >> + guard(spinlock)(&dmabuf->name_lock); >> + trace_dma_buf_export(dmabuf); >> + } >> + > > perhaps a macro similar to the one below > > #define DMA_BUF_TRACE(FUNC, ...) \ > do { \ > if (FUNC##_enabled()) { \ > guard(spinlock)(&dmabuf->name_lock); \ > FUNC(__VA_ARGS__); \ > } \ > } while (0) > > > This would help us avoid duplicating a lot of code. > > could be: > DMA_BUF_TRACE(trace_dma_buf_put, dmabuf); > DMA_BUF_TRACE(trace_dma_buf_attach, dmabuf, dev); > > ? Thinking more about it I was wondering if we really need the userspace assigned name in the tracepoint in the first place. The ino should be sufficient to uniquely identify each dma-buf, tracing the name should only be printed if it's changing or otherwise we spam the tracelog quite a bit with it. BTW We don't have any identification for an attachment, so when multiple devices attach to the same DMA-buf the trace would be quite meaningless. We should probably fix that. Regards, Christian.
