Re: [PATCH 4/9] dma-buf: heaps: Add debugfs support

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2852 bytes --]

On Wed, Sep 03, 2025 at 11:48:38AM -0700, John Stultz wrote:
> On Wed, Sep 3, 2025 at 8:38 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Tue, Sep 02, 2025 at 03:37:45PM -0700, John Stultz wrote:
> > > On Tue, Sep 2, 2025 at 8:46 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > >
> > > > From: Thierry Reding <treding@nvidia.com>
> > > >
> > > > Add a callback to struct dma_heap_ops that heap providers can implement
> > > > to show information about the state of the heap in debugfs. A top-level
> > > > directory named "dma_heap" is created in debugfs and individual files
> > > > will be named after the heaps.
> > > >
> > >
> > > I know its debugfs, but this feels a little loosey-goosey as an uAPI.
> >
> > Well, the whole point of debugfs is that it's not really an ABI. Nothing
> > should ever rely on the presence of these files.
> >
> > > Is there any expected format for the show function?
> > >
> > > What would other dmabuf heaps ideally export via this interface?
> >
> > I've thought about this a bit and I'm not sure it makes sense to
> > standardize on this. I think on one hand having a list of buffers
> > exported by the dma-buf heap is probably the lowest common denominator,
> > but then there might be a bunch of other things that are very heap-
> > specific that some heap might want to export.
> >
> > > Is there some consistent dma_heap-ish concept for it to justify it
> > > being under a dma_heap directory, and not just an independent debugfs
> > > file for the driver implementing the dmabuf heap?
> >
> > Well, I think just the fact that it's a dma-heap would qualify its
> > corresponding debugfs to be in a well-known location. We could of course
> > pick some arbitrary location, but that's just a recipe for chaos because
> > then everybody puts these whereever they want. There's really no
> > standard place for driver-specific debugfs files to go, so putting it
> > into some "subsystem"-specific directory seems like the better option.
> 
> Ok, I guess I was thinking if the files are organizationally cohesive
> to be under the dma-heap directory, they ought to have some
> consistency between them.

As far as I can tell there's not even enough information in a dma-heap
to add any common debugfs snippets. As I mentioned earlier, a list of
buffers allocated from a dma-heap is about the only generic piece of
information that I can think of, but we don't track these buffers in a
generic way. None of the existing heaps do so either seem to be
interested in this either.

It's also not like it's very useful information most of the time, it's
mainly in this driver so that it can be inspected at runtime to see what
the allocation pattern looks like at various stages and maybe help tune
the division into chunks.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]