Re: [PATCH v14 00/16] Refcounted interrupts, SpinLockIrq for rust

[John Hubbard]

On 11/21/25 7:35 PM, Boqun Feng wrote:
> On Fri, Nov 21, 2025 at 06:56:28PM -0800, John Hubbard wrote:
> > On 11/21/25 6:38 PM, Boqun Feng wrote:
> [...]
> > > Last but not least, safe Rust is preferred, but it doesn't mean unsafe
> > > code should be avoided completely, if we establish some data that shows
> >
> > Perhaps we need to be slightly more precise. I'm not sure if you are
> > referring to the usual practice of creating an unsafe block, wrapped
> > within a safe Rust function, or something else?
>
> I was referring to providing an unsafe API for core kernel
> functionality, for example local_irq_disable(), and then teaching how to
> use it correctly.

Ack.

> > > some unsafe code provides better performance and we have clear guideline
> > > for the particular scenarios, then it's definitely OK. Hence I don't
> > > fully agree your saying "Safe Rust is the whole point of this project",
> > > to me understanding how we can utilize the type system and other tools
> > > is more of a realistic goal.
> > >
> > > > Is 3.6x longer really something we are stuck with? Or is there some other
> > > > way forward that could potentially provide higher performance, for Safe
> > > > Rust?
> > >
> > > Well by 3.6x longer, you mean ~1.3ns vs ~4.5ns, right? And in real world
> > > code, the code in the interrupt disabling critical section would be more
> > > than couples of nano seconds, hence the delta will probably be
> > > noise-out. But again, yes if 3ns turns out to be a bottleneck in the
> > > driver, we are happy to look into, but you need to show the data.
> >
> > So this is what I'm asking about: given that we *already know* that we
> > have a performance drop in the micro-benchmark, is there any reasonable
> > approach that avoids this? Or has a less noticeable impact?
>
> Lyude had tried another approach [1], which uses an unsafe public API,
> and doesn't work (easily) with CondVar or PREEMPT_RT And that eventually
> triggered more discussion about a better API design, and as Thomas
> pointed out [2]: "Stop worrying about mostly irrelevant low level
> details which are not relevant to the primary audience of rust adoption.
> We can worry about them when we replace the scheduler and the low level
> interrupt handling code ten years down the road." And I agreed. The
> current implementation is actually quite efficient and should even
> out-perform the existing API in some cases as I pointed out. More
> importantly, it utilizes Rust type system and make it easy to use (or
> hard to mis-use).
>
> That being said, if anyone has a better idea, feel free to bring it up.
>
> > I'm asking early (see above: I agree that this is "premature"), because
> > we have early data.
> >
> > It would be nice to explore now, rather than later, after someone shows
> > up with detailed perf data about their use case.
>
> Not sure I fully agree with this, given it's to my knowledge the best
> solution at the moment, I feel it's hard to justify the cost of
> exploring a better solution without a real usage. But then again, if
> anyone has any better idea feel free to bring it up.
>
> [1]: https://lore.kernel.org/rust-for-linux/20240916213025.477225-2-lyude@xxxxxxxxxx/
> [2]: https://lore.kernel.org/rust-for-linux/87iktrahld.ffs@tglx/

Thanks for this context, I hadn't followed the earlier discussions,
and when looking at this v14, it seemed to gloss over the performance
implications (they were linked to, but not discussed).

I won't further harass you all about this, let's see how it goes. :)

Optionally, it might be helpful to include some top-level notes
that justify the choices made so far.

thanks,
--
John Hubbard