From: Joel Fernandes <joel@joelfernandes.org>
To: Chenbo Feng <fengc@google.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-media@vger.kernel.org, kernel-team@android.com,
Sumit Semwal <sumit.semwal@linaro.org>,
erickreyes@google.com, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [RFC v2 dma-buf 0/3] Improve the dma-buf tracking
Date: Fri, 22 Mar 2019 08:29:47 -0400 [thread overview]
Message-ID: <20190322122947.GA47151@google.com> (raw)
In-Reply-To: <20190322025135.118201-1-fengc@google.com>
On Thu, Mar 21, 2019 at 07:51:32PM -0700, Chenbo Feng wrote:
> Currently, all dma-bufs share the same anonymous inode. While we can count
> how many dma-buf fds or mappings a process has, we can't get the size of
> the backing buffers or tell if two entries point to the same dma-buf. And
> in debugfs, we can get a per-buffer breakdown of size and reference count,
> but can't tell which processes are actually holding the references to each
> buffer.
>
> To resolve the issue above and provide better method for userspace to track
> the dma-buf usage across different processes, the following changes are
> proposed in dma-buf kernel side. First of all, replace the singleton inode
> inside the dma-buf subsystem with a mini-filesystem, and assign each
> dma-buf a unique inode out of this filesystem. With this change, calling
> stat(2) on each entry gives the caller a unique ID (st_ino), the buffer's
> size (st_size), and even the number of pages assigned to each dma-buffer.
> Secoundly, add the inode information to /sys/kernel/debug/dma_buf/bufinfo
> so in the case where a buffer is mmap()ed into a process’s address space
Is there a better place to add bufinfo than debugfs, since debugfs is not
something Android may mount for non-debug uses in the future?
> but all remaining fds have been closed, we can still get the dma-buf
> information and try to accociate it with the process by searching the
> proc/pid/maps and looking for the corresponding inode number exposed in
> dma-buf debug fs. Thirdly, created an ioctl to assign names to dma-bufs
> which lets userspace assign short names (e.g., "CAMERA") to buffers. This
> information can be extremely helpful for tracking and accounting shared
> buffers based on their usage and original purpose. Last but not least, add
> dma-buf information to /proc/pid/fdinfo by adding a show_fdinfo() handler
> to dma_buf_file_operations. The handler will print the file_count and name
> of each buffer.
There are a couple more entries shown in fdinfo per patch 3/3 so it is worth
mentioning those here as well.
Also, is there kselftests to add or modify? I suggest we add those since they
are always invaluable.
I'll review more soon. Currently traveling. I am especially curious how you
created the new inodes since I recently had to do so for another usecase as
well. thanks!
- Joel
>
> Change in v2:
> * Add a check to prevent changing dma-buf name when it is attached to
> devices.
> * Fixed some compile warnings
>
> Greg Hackmann (3):
> dma-buf: give each buffer a full-fledged inode
> dma-buf: add DMA_BUF_{GET,SET}_NAME ioctls
> dma-buf: add show_fdinfo handler
>
> drivers/dma-buf/dma-buf.c | 121 ++++++++++++++++++++++++++++++++---
> include/linux/dma-buf.h | 5 +-
> include/uapi/linux/dma-buf.h | 4 ++
> include/uapi/linux/magic.h | 1 +
> 4 files changed, 122 insertions(+), 9 deletions(-)
>
> --
> 2.21.0.rc2.261.ga7da99ff1b-goog
>
prev parent reply other threads:[~2019-03-22 12:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-22 2:51 [RFC v2 dma-buf 0/3] Improve the dma-buf tracking Chenbo Feng
2019-03-22 2:51 ` [RFC v2 1/3] dma-buf: give each buffer a full-fledged inode Chenbo Feng
2019-03-22 15:02 ` Joel Fernandes
2019-03-24 17:56 ` Sandeep Patil
2019-03-24 20:44 ` Joel Fernandes
2019-03-25 19:34 ` Chenbo Feng
2019-03-25 21:47 ` Joel Fernandes
2019-03-25 21:48 ` Erick Reyes
2019-03-25 21:48 ` Erick Reyes
2019-03-22 2:51 ` [RFC v2 2/3] dma-buf: add DMA_BUF_{GET,SET}_NAME ioctls Chenbo Feng
2019-03-22 2:51 ` [RFC v2 3/3] dma-buf: add show_fdinfo handler Chenbo Feng
2019-03-22 12:29 ` Joel Fernandes [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=20190322122947.GA47151@google.com \
--to=joel@joelfernandes.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=erickreyes@google.com \
--cc=fengc@google.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.