[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPhsuW4f2=M_K553+BVnGJq=ddZ7sXj4CfCAHeYQ=4cpihBCzA@mail.gmail.com>
Date: Wed, 16 Apr 2025 21:56:42 -0700
From: Song Liu <song@...nel.org>
To: "T.J. Mercier" <tjmercier@...gle.com>
Cc: sumit.semwal@...aro.org, christian.koenig@....com, ast@...nel.org,
daniel@...earbox.net, andrii@...nel.org, martin.lau@...ux.dev,
skhan@...uxfoundation.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linaro-mm-sig@...ts.linaro.org, linux-doc@...r.kernel.org,
bpf@...r.kernel.org, linux-kselftest@...r.kernel.org, android-mm@...gle.com,
simona@...ll.ch, corbet@....net, eddyz87@...il.com, yonghong.song@...ux.dev,
john.fastabend@...il.com, kpsingh@...nel.org, sdf@...ichev.me,
jolsa@...nel.org, mykolal@...com
Subject: Re: [PATCH 2/4] bpf: Add dmabuf iterator
On Wed, Apr 16, 2025 at 7:09 PM T.J. Mercier <tjmercier@...gle.com> wrote:
>
> On Wed, Apr 16, 2025 at 6:26 PM Song Liu <song@...nel.org> wrote:
[...]
> >
> > Here is another rookie question, it appears to me there is a file descriptor
> > associated with each DMA buffer, can we achieve the same goal with
> > a task-file iterator?
>
> That would find almost all of them, but not the kernel-only
> allocations. (kernel_rss in the dmabuf_dump output I attached earlier.
> If there's a leak, it's likely to show up in kernel_rss because some
> driver forgot to release its reference(s).) Also wouldn't that be a
> ton more iterations since we'd have to visit every FD to find the
> small portion that are dmabufs? I'm not actually sure if buffers that
> have been mapped, and then have had their file descriptors closed
> would show up in task_struct->files; if not I think that would mean
> scanning both files and vmas for each task.
I don't think scanning all FDs to find a small portion of specific FDs
is a real issue. We have a tool that scans all FDs in the system and
only dump data for perf_event FDs. I think it should be easy to
prototype a tool by scanning all files and all vmas. If that turns out
to be very slow, which I highly doubt will be, we can try other
approaches.
OTOH, I am wondering whether we can build a more generic iterator
for a list of objects. Adding a iterator for each important kernel lists
seems not scalable in the long term.
Thanks,
Song
Powered by blists - more mailing lists