Message-ID: <e11bd713-2404-449b-ab63-7d6c0dc47b4b@nvidia.com>
Date: Fri, 21 Nov 2025 18:56:28 -0800
From: John Hubbard <jhubbard@...dia.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Lyude Paul <lyude@...hat.com>, rust-for-linux@...r.kernel.org,
 linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
 Daniel Almeida <daniel.almeida@...labora.com>,
 Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
 Gary Guo <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>,
 Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
 Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
 Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>
Subject: Re: [PATCH v14 00/16] Refcounted interrupts, SpinLockIrq for rust

On 11/21/25 6:38 PM, Boqun Feng wrote:
> 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:
>>>> ...
>> 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.

Yes, it is. :)

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

This argument doesn't apply directly, because the response to "Safe Rust
is slower in this case", is "the slowdown is justified".

Perhaps it is, but that doesn't refute the claim. It's still slower.

Maybe that's not a problem at all, but it's not yet clear.

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

Yes, we have already mentioned several times that micro-benchmarks are
not the final word. However, they can be an early indication of a problem.

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

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

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.


thanks,
-- 
John Hubbard

Powered by blists - more mailing lists