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

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

On Fri, Nov 21, 2025 at 05:09:24PM -0800, John Hubbard wrote:
> On 11/21/25 9:47 AM, Boqun Feng wrote:
> > On Thu, Nov 20, 2025 at 03:16:04PM -0800, John Hubbard wrote:
> >> On 11/20/25 1:45 PM, Lyude Paul wrote:
> >> ...
> >> This is alarming, but is it the final word? In other words, is the Rust
> >> side of this doomed to slower performance forever, or is there some
> >> hope of reaching performance parity with the C part of the kernel?
> >>
> > 
> > Note that local_interrupt API is for safe Rust code, you can always
> > use unsafe local_irq if the interrupt disabling is the performance
> > bottleneck for you. So language-wise there is no difference between Rust
> > and C.
> >
> 
> OK, but there *is* a performance difference between Safe Rust (which is
> the whole point of this project, after all) and C.
> 

Again, this is a premature statement.

First of all, the safe SpinLockIrq API is made to work with other API
like CondVar, there are certain design requirements making it being
implemented in a certain way. In other words, the cost is justified.

Second, one safe API being slow than unsafe code or C doesn't mean Safe
Rust is slow than C in all the cases.

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
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.

>  
> >> Do we have to start telling the Rust for Linux story this way: "our
> >> new Rust-based drivers are slower, but memory-safer"?
> >>
> > 
> > I would not jump into that conclusion at the moment, because 1) as I
> > mentioned you can always go into unsafe if something begins the
> > bottleneck, and 2) there is always a gap between micro benchmark results
> > and the whole system performance, being slow on one operation doesn't
> > means the whole system will perform observably worse.
> > 
> > Think about a similar thing in C, we recommend people to use existing
> > locks instead of customized synchronization vi atomics in most cases,
> > and technically, locks can be slower compared to a special
> > synchronization based on atomics, but it's more difficult to mess up.
> > 
> 
> Yes yes, I fully understand that micro benchmarks don't always translate
> to a real-world observable effects. But interrupt operations...those can
> be on a hot path. So it's prudent to worry about these.
> 

Note that it's the interrupt *disabling* operations, which means the
code could be otherwise interrupted outside the critical section, so yes
it could still be hot path, but there are more things than 3ns to affect
here.

Also one thing to notice is that

	local_interrupt_disable();
	<some other function>
	local_interrupt_disable();

should be cheaper than

	local_irq_save();
	<some other function>
	local_irq_save();

because the latter will access the interrupt disabling register twice.
So it's really hard to say whether the new API is strictly worse than
the existing ones.

Regards,
Boqun

> 
> thanks,
> -- 
> John Hubbard
>