On 12/1/25 02:44, 高翔 wrote: >> 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.
Yeah, it probably do in most use cases. I just want to cover all use cases. Maybe just use %p to print the attachment pointer until we have something better. > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *发件人:* 高翔 > *发送时间:* 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. The DMA-buf "name" is an userspace assigned name and *not* useable for what you suggest here. E.g. it is usually something like "texture", "shader", "dummy", "global".... Could be that you have a driver or use case where it is something more specific and we can keep it where it makes sense for you, but I strongly suggest to always print the ino first since that one is guaranteed to be unique. Regards, Christian. > > >> 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. >
