Re: [RFC PATCH 3/4] rust/drm: Add DRM Jobqueue

[Alice Ryhl <aliceryhl@google.com>]

On Wed, Feb 11, 2026 at 04:20:15PM +0100, Philipp Stanner wrote:
> On Wed, 2026-02-11 at 15:17 +0000, Alice Ryhl wrote:
> > On Wed, Feb 11, 2026 at 03:07:38PM +0100, Boris Brezillon wrote:
> > > 
> > > Back to this particular job dependencies use case: we have to embed the
> > > DmaFence pointer in some wrapper with the ListLinks element anyway,
> > > because DmaFences can be inserted in multiple of those lists in
> > > parallel.
> > 
> > Okay, if that's the case, then the linked list is *really* not the right
> > tool for the job.
> 
> We have to distinguish what we are talking about here.
> 
> For the JobQueue, it takes over a cloned DmaFence and stuffs that into
> its own list. Problem solved.
> 
> Whether the driver has other clones of that fence in other list is not
> relevant because it's not the same list head.
> 
> JQ's lists and list heads are internal.
> 
> I don't see a problem.

I'm talking about this allocation:

    pub fn add_dependency(&mut self, fence: ARef<DmaFence<i32>>) -> Result {
        let dependency = Dependency::new(fence)?;

and this one:

    pub fn submit_job(&self, mut job: Pin<KBox<Job<T>>>) -> Result<ARef<DmaFence<i32>>> {
        [...]
        let wrapped_job = JobWrap::new(job)?;

Replacing `dependencies` with a KVec and `waiting_jobs` with xarray
would cause these to use less memory, fewer allocations, and be faster.
And it would solve the raw pointer in HwFenceWaker, as you can use the
address (or other ID) of the Job<T> as key to look up in the xarray.

For `dependencies` there's no need to worry about the vector growing too
large, because the vectors are not long-lived: when the fence signalled
the entire vector can be freed. As for waiting_jobs, the xarray
auto-shrinks its memory usage, so no problem there.

Alice