From: Steven Rostedt <rostedt@goodmis.org>
To: Xiang Gao <gxxa03070307@gmail.com>
Cc: sumit.semwal@linaro.org, christian.koenig@amd.com,
mhiramat@kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
mathieu.desnoyers@efficios.com, dhowells@redhat.com,
kuba@kernel.org, brauner@kernel.org, akpm@linux-foundation.org,
linux-trace-kernel@vger.kernel.org,
gaoxiang17 <gaoxiang17@xiaomi.com>
Subject: Re: [PATCH v11] dma-buf: add some tracepoints to debug.
Date: Fri, 26 Dec 2025 11:42:15 -0500 [thread overview]
Message-ID: <20251226114215.02be95a3@gandalf.local.home> (raw)
In-Reply-To: <20251225121119.2194228-1-gxxa03070307@gmail.com>
On Thu, 25 Dec 2025 20:11:19 +0800
Xiang Gao <gxxa03070307@gmail.com> wrote:
> From: gaoxiang17 <gaoxiang17@xiaomi.com>
>
> 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:3016_1-3102 [006] ...1. 255.126521: dma_buf_export: exp_name=qcom,system size=12685312 ino=2738
> binder:3016_1-3102 [006] ...1. 255.126528: dma_buf_fd: exp_name=qcom,system size=12685312 ino=2738 fd=8
> binder:3016_1-3102 [006] ...1. 255.126642: dma_buf_mmap_internal: exp_name=qcom,system size=28672 ino=2739
> kworker/6:1-86 [006] ...1. 255.127194: dma_buf_put: exp_name=qcom,system size=12685312 ino=2738
> RenderThread-9293 [006] ...1. 316.618179: dma_buf_get: exp_name=qcom,system size=12771328 ino=2762 fd=176
> RenderThread-9293 [006] ...1. 316.618195: dma_buf_dynamic_attach: exp_name=qcom,system size=12771328 ino=2762 attachment:ffffff880a18dd00 is_dynamic=0 dev_name=kgsl-3d0
> RenderThread-9293 [006] ...1. 318.878220: dma_buf_detach: exp_name=qcom,system size=12771328 ino=2762 attachment:ffffff880a18dd00 is_dynamic=0 dev_name=kgsl-3d0
>
> Signed-off-by: Xiang Gao <gaoxiang17@xiaomi.com>
> ---
>
> Changes since v10: https://lore.kernel.org/all/20251224013455.1649879-1-gxxa03070307@gmail.com/
You only need to show the last revision (but since you haven't showed the
others, before it's good to show them now). But you also want to say "what changed"
For example:
- Used DEFINE_EVENT_CONDITION() to move the condition branch into the tracepoint.
> Changes since v9: https://lore.kernel.org/all/20251223032749.1371913-1-gxxa03070307@gmail.com/
> Changes since v8: https://lore.kernel.org/all/20251218062853.819744-1-gxxa03070307@gmail.com/
> Changes since v7: https://lore.kernel.org/all/20251217105132.643300-1-gxxa03070307@gmail.com/
> Changes since v6: https://lore.kernel.org/all/20251216063952.516364-1-gxxa03070307@gmail.com/
> Changes since v5: https://lore.kernel.org/all/20251201112148.843572-1-gxxa03070307@gmail.com/
> Changes since v4: https://lore.kernel.org/all/20251128085215.550100-1-gxxa03070307@gmail.com/
> Changes since v3: https://lore.kernel.org/all/20251127004352.376307-1-gxxa03070307@gmail.com/
> Changes since v2: https://lore.kernel.org/all/20251125162949.220488-1-gxxa03070307@gmail.com/
> Changes since v1: https://lore.kernel.org/all/20251124133648.72668-1-gxxa03070307@gmail.com/
>
> drivers/dma-buf/dma-buf.c | 48 +++++++++-
> include/trace/events/dma_buf.h | 159 +++++++++++++++++++++++++++++++++
> 2 files changed, 205 insertions(+), 2 deletions(-)
> create mode 100644 include/trace/events/dma_buf.h
>
> +/*
> + * dmabuf->name must be accessed with holding dmabuf->name_lock.
> + * we need to take the lock around the tracepoint call itself where
> + * it is called in the code.
> + *
> + * Note: FUNC##_enabled() is a static branch that will only
> + * be set when the trace event is enabled.
> + */
> +#define DMA_BUF_TRACE(FUNC, ...) \
> + do { \
> + /* Always expose lock if lockdep is enabled */ \
> + if (IS_ENABLED(CONFIG_LOCKDEP) || FUNC##_enabled()) { \
> + guard(spinlock)(&dmabuf->name_lock); \
> + FUNC(__VA_ARGS__); \
> + } \
> + } while (0)
> +
> static inline int is_dma_buf_file(struct file *);
>
> +
> +DEFINE_EVENT_CONDITION(dma_buf_fd, dma_buf_fd,
> +
> + TP_PROTO(struct dma_buf *dmabuf, int fd),
> +
> + TP_ARGS(dmabuf, fd),
> +
> + TP_CONDITION(fd >= 0)
> +);
> +
From a tracing point of view (It's up to the dma maintainers to decide to
take this patch):
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
prev parent reply other threads:[~2025-12-26 16:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-25 12:11 [PATCH v11] dma-buf: add some tracepoints to debug Xiang Gao
2025-12-26 16:42 ` Steven Rostedt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251226114215.02be95a3@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=christian.koenig@amd.com \
--cc=dhowells@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gaoxiang17@xiaomi.com \
--cc=gxxa03070307@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=sumit.semwal@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox