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

[Alice Ryhl <aliceryhl@google.com>]

On Wed, Feb 11, 2026 at 01:44:56PM +0100, Philipp Stanner wrote:
> On Wed, 2026-02-11 at 12:22 +0000, Alice Ryhl wrote:
> > On Wed, Feb 11, 2026 at 12:19:56PM +0100, Philipp Stanner wrote:
> > > On Wed, 2026-02-11 at 12:07 +0100, Boris Brezillon wrote:
> > > > On Wed, 11 Feb 2026 11:47:27 +0100
> > > > Philipp Stanner <phasta@mailbox.org> wrote:
> > > > 
> > > > > On Tue, 2026-02-10 at 15:57 +0100, Boris Brezillon wrote:
> > > > > > On Tue,  3 Feb 2026 09:14:02 +0100
> > > > > > Philipp Stanner <phasta@kernel.org> wrote:
> > > > > >   
> > > > > > > +/// A jobqueue Job.
> > > > > > > +///
> > > > > > > +/// You can stuff your data in it. The job will be borrowed back to your driver
> > > > > > > +/// once the time has come to run it.
> > > > > > > +///
> > > > > > > +/// Jobs are consumed by [`Jobqueue::submit_job`] by value (ownership transfer).
> > > > > > > +/// You can set multiple [`DmaFence`] as dependencies for a job. It will only
> > > > > > > +/// get run once all dependency fences have been signaled.
> > > > > > > +///
> > > > > > > +/// Jobs cost credits. Jobs will only be run if there are is enough capacity in
> > > > > > > +/// the jobqueue for the job's credits. It is legal to specify jobs costing 0
> > > > > > > +/// credits, effectively disabling that mechanism.
> > > > > > > +#[pin_data]
> > > > > > > +pub struct Job<T: 'static + Send> {
> > > > > > > +    cost: u32,
> > > > > > > +    #[pin]
> > > > > > > +    pub data: T,
> > > > > > > +    done_fence: Option<ARef<DmaFence<i32>>>,
> > > > > > > +    hardware_fence: Option<ARef<DmaFence<i32>>>,
> > > > > > > +    nr_of_deps: AtomicU32,
> > > > > > > +    dependencies: List<Dependency>,  
> > > > > > 
> > > > > > Given how tricky Lists are in rust, I'd recommend going for an XArray,
> > > > > > like we have on the C side. There's a bit of overhead when the job only
> > > > > > has a few deps, but I think simplicity beats memory-usage-optimizations
> > > > > > in that case (especially since the overhead exists and is accepted in
> > > > > > C).  
> > > > > 
> > > > > I mean, the list is now already implemented and works. Considering the
> > > > > XArray would have made sense during the development difficulties.
> > > > 
> > > > I'm sure it does, but that's still more code/tricks to maintain than
> > > > what you'd have with the XArray abstraction.
> > > 
> > > The solution than will rather be to make the linked list implementation
> > > better.
> > > 
> > > A list is the correct data structure in a huge number of use cases in
> > > the kernel. We should not begin here to defer to other structures
> > > because of convenience.
> > 
> > Rust vs C aside, linked lists are often used in the kernel despite not
> > being the best choice. They are extremely cache unfriendly and
> > inefficient; most of the time a vector or xarray is far faster if you
> > can accept an ENOMEM failure path when adding elements. I have heard
> > several times from C maintainers that overuse of list is making the
> > kernel slow in a death from a thousand cuts situation.
> 
> Interesting. Valid points.
> 
> It might be a self-accelerating thing. More people have lists on their
> mind because they are so common, with RB trees et al. being relatively
> rare, so they instinctively use them, making them more common…

Yes, many people assume "list widely used in kernel" implies "list is a
good idea". Unfortunately it is not the case.

> > This applies to the red/black tree too, by the way.
> 
> Can't fully follow, you mean that RB trees are supposedly overused,
> too?

When I first suggested adding red/black tree abstractions in Rust
several years ago I was told by Greg that I couldn't do it because the
red/black tree was deprecated and no new users should be added.

Later I found that this was more of a not-written-down recommendation
than a full deprecation, and since Rust Binder has codepaths where an
ENOMEM failure path is unacceptable for the map, we did end up adding a
Rust rb tree abstraction after all. But this is where I first heard of
this issue with lists and rb trees.

Alice