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 <[email protected]> wrote: > > > > > > > > > On Tue, 2026-02-10 at 15:57 +0100, Boris Brezillon wrote: > > > > > > On Tue, 3 Feb 2026 09:14:02 +0100 > > > > > > Philipp Stanner <[email protected]> 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
