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

[Boqun Feng <boqun.feng@gmail.com>]

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.

> > 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@redhat.com/
[2]: https://lore.kernel.org/rust-for-linux/87iktrahld.ffs@tglx/

Regards,
Boqun

> thanks,
> -- 
> John Hubbard