On Wed, 2026-02-11 at 12:59 +0100, Boris Brezillon wrote:
> On Wed, 11 Feb 2026 12:19:56 +0100
> Philipp Stanner <[email protected]> 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.
> >
> > Btw. lists in Rust being so horrible has been repeatedly a reason why
> > some other hackers argued that Rust as a language is not suitable for
> > kernel development.
> >
> > So getting that right seems more desirable than capitulating.
>
> I'm not capitulating, and I'm not saying "No list, never!" either. I'm
> saying, if there's something that fits the bill and is easier to use,
> maybe we should consider it...
>
> >
> > >
> > > >
> > > > If it were to make sense we could certainly replace the list with an
> > > > xarray, but I don't see an advantage. The JQ just needs to iterate over
> > > > the dependencies to register its events on them, and on drop to
> > > > deregister them perhaps.
> > > >
> > > > We have many jobs, but likely only few dependencies per job, so the
> > > > lower memory footprint seems desirable and the XArray's advantages
> > > > don't come to play – except maybe if we'd want to consider to avoid the
> > > > current unsafe-rawpointer solution to obtain the job, since obtaining a
> > > > job from an Xarray is far faster than by list iteration.
> > >
> > > I don't think we need O(1) for picking random deps in a job, because
> > > that's not something we need at all: the dep list here is used as a
> > > FIFO.
> > >
> >
> > Wrong. The dep list here has no ordering requirements at all. JQ does
> > not care in which order it registers its events, it just cares about
> > dealing with dep-fences racing.
>
> What I mean is that it's used as a FIFO right now, not that deps have to
> be processed in order.
Yeah, but it being a FIFO is irrelevant :)
>
> >
> > You could (de-)register your callbacks in random order, it does not
> > matter.
>
> Again, that's not my point, and I think we're just saying the same
> thing here: the list seems to be a good match for this dependency
> array/list, because right now deps are processed in order. Now, being
> the right construct in one language doesn't mean it's the right
> construct in another language.
>
> >
> > List and Xarray might be useful for the unsafe related to the
> > DependencyWaker. There you could avoid a raw pointer by getting the job
> > through a list iteration or through the hypothetical XArray.
> >
> > Please take a look at my detailed code comments for DependencyWaker.
>
> Sure, I'll have a closer look.
>
> >
> > > There's the per-dep overhead of the ListLinks object maybe, but
> > > it's certainly acceptable. And I don't think cache locality matters
> > > either, because the XArray stores pointers too, so we'll still be one
> > > deref away from the DmaFence. No, my main concern was maintainability,
> > > because managing lists in rust is far from trivial, and as a developer,
> > > I try to avoid using concepts the language I rely on is not friendly
> > > with.
> >
> > This would be a decision with wide implications, as detailed above.
> >
> > If we were to admit that lists just don't work in Rust, then wouldn't
> > the consequent decision to remove them all together?
>
> I'm not going as far as saying they don't work, I'm just saying they
> are trickier to use, and that's a fact.
>
> >
> > "Lists in kernel-Rust are not supported. Too difficult to maintain.
> > We're sorry. Use XArray et al. instead :("
>
> No, there are patterns where an XArray wouldn't be a good fit. For
> instance, LRU lists where objects get moved between lists depending on
> their usage pattern. If we were to use XArrays for that, that would
> imply potential allocations in paths where we don't want them. In this
> dep array case, the deps are added at submit time, and they get
> progressively dropped, so the array can't grow, it can only ever
> shrink, and XArray allows it to shrink from both ends (and even have
> holes), so it sounds like a good match too. Not saying a perfect match,
> not saying better than a list in general, but an XArray is easier to
> use than a list **in rust**, and the fact it fits the bill (if it does
> in C, it should in rust too) had me thinking that maybe it's what we
> should use.
Yoah, you have valid points.
Since XArray allows for dropping the unsafe {} without the performance
penalty of a list-iteration, I think your idea for this particular case
is good after all and can be put on the TODO list.
I'm not sure how soon I have the cycles for implementing that, though.
Looks as if a ton of work is coming at us for dma_fence.
P.
