[PATCH 0/4] Replace CONFIG_DMABUF_SYSFS_STATS with BPF

Christian König christian.koenig at amd.com
Tue Apr 15 09:03:04 UTC 2025


Am 15.04.25 um 00:52 schrieb T.J. Mercier:
> Until CONFIG_DMABUF_SYSFS_STATS was added [1] it was only possible to
> perform per-buffer accounting with debugfs which is not suitable for
> production environments. Eventually we discovered the overhead with
> per-buffer sysfs file creation/removal was significantly impacting
> allocation and free times, and exacerbated kernfs lock contention. [2]
> dma_buf_stats_setup() is responsible for 39% of single-page buffer
> creation duration, or 74% of single-page dma_buf_export() duration when
> stressing dmabuf allocations and frees.
>
> I prototyped a change from per-buffer to per-exporter statistics with a
> RCU protected list of exporter allocations that accommodates most (but
> not all) of our use-cases and avoids almost all of the sysfs overhead.
> While that adds less overhead than per-buffer sysfs, and less even than
> the maintenance of the dmabuf debugfs_list, it's still *additional*
> overhead on top of the debugfs_list and doesn't give us per-buffer info.
>
> This series uses the existing dmabuf debugfs_list to implement a BPF
> dmabuf iterator, which adds no overhead to buffer allocation/free and
> provides per-buffer info.

Really interesting suggestion. I was expecting something like cgroups, but bpf is certainly an option as well.

How do you then use bpf to account the buffers? E.g. are you interacting with cgroups or have sysfs procedure to expose the list or how does that work?

Additional to that why using DMA-buf for accounting in the first place? See DMA-buf is for sharing buffers and only a minimal fraction of buffers usually need to get shared. Everything else is just massive overhead.

> While the kernel must have CONFIG_DEBUG_FS for
> the dmabuf_iter to be available, debugfs does not need to be mounted.
> The BPF program loaded by userspace that extracts per-buffer information
> gets to define its own interface which avoids the lack of ABI stability
> with debugfs (even if it were mounted).

I think we can make the buffer list independent of CONFIG_DEBUG_FS.

> As this is a replacement for our use of CONFIG_DMABUF_SYSFS_STATS, the
> last patch is a RFC for removing it from the kernel. Please see my
> suggestion there regarding the timeline for that.

Oh, yes please!

Regards,
Christian.

>
> [1] https://lore.kernel.org/linux-media/20201210044400.1080308-1-hridya@google.com/
> [2] https://lore.kernel.org/all/20220516171315.2400578-1-tjmercier@google.com/
>
> T.J. Mercier (4):
>   dma-buf: Rename and expose debugfs symbols
>   bpf: Add dmabuf iterator
>   selftests/bpf: Add test for dmabuf_iter
>   RFC: dma-buf: Remove DMA-BUF statistics
>
>  .../ABI/testing/sysfs-kernel-dmabuf-buffers   |  24 ---
>  Documentation/driver-api/dma-buf.rst          |   5 -
>  drivers/dma-buf/Kconfig                       |  15 --
>  drivers/dma-buf/Makefile                      |   1 -
>  drivers/dma-buf/dma-buf-sysfs-stats.c         | 202 ------------------
>  drivers/dma-buf/dma-buf-sysfs-stats.h         |  35 ---
>  drivers/dma-buf/dma-buf.c                     |  40 +---
>  include/linux/btf_ids.h                       |   1 +
>  include/linux/dma-buf.h                       |   6 +
>  kernel/bpf/Makefile                           |   3 +
>  kernel/bpf/dmabuf_iter.c                      | 130 +++++++++++
>  tools/testing/selftests/bpf/config            |   1 +
>  .../selftests/bpf/prog_tests/dmabuf_iter.c    | 116 ++++++++++
>  .../testing/selftests/bpf/progs/dmabuf_iter.c |  31 +++
>  14 files changed, 299 insertions(+), 311 deletions(-)
>  delete mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers
>  delete mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c
>  delete mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h
>  create mode 100644 kernel/bpf/dmabuf_iter.c
>  create mode 100644 tools/testing/selftests/bpf/prog_tests/dmabuf_iter.c
>  create mode 100644 tools/testing/selftests/bpf/progs/dmabuf_iter.c
>



More information about the dri-devel mailing list