mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: lyude@redhat.com
To: Gary Guo <gary@garyguo.net>,
	rust-for-linux@vger.kernel.org,  linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>
Cc: "Boqun Feng" <boqun.feng@gmail.com>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>, "Will Deacon" <will@kernel.org>,
	"Waiman Long" <longman@redhat.com>
Subject: Re: [PATCH v18 5/5] rust: sync: Introduce SpinLockIrq::lock_with() and friends
Date: Mon, 02 Mar 2026 17:47:03 -0500	[thread overview]
Message-ID: <482ef57154db2d58e1907a1648816ee31f2045a2.camel@redhat.com> (raw)
In-Reply-To: <DG7EYT29W3CY.2WMEH783JP7RI@garyguo.net>

On Thu, 2026-02-05 at 23:23 +0000, Gary Guo wrote:
> On Thu Feb 5, 2026 at 8:44 PM GMT, Lyude Paul wrote:
> > `SpinLockIrq` and `SpinLock` use the exact same underlying C
> > structure,
> > with the only real difference being that the former uses the
> > irq_disable()
> > and irq_enable() variants for locking/unlocking. These variants can
> > introduce some minor overhead in contexts where we already know
> > that
> > local processor interrupts are disabled, and as such we want a way
> > to be
> > able to skip modifying processor interrupt state in said contexts
> > in order
> > to avoid some overhead - just like the current C API allows us to
> > do.
> > 
> > In order to do this, we add some special functions for SpinLockIrq:
> > lock_with() and try_lock_with(), which allow acquiring the lock
> > without
> > changing the interrupt state - as long as the caller can provide a
> > LocalInterruptDisabled reference to prove that local processor
> > interrupts
> > have been disabled.
> > 
> > In some hacked-together benchmarks we ran, most of the time this
> > did
> > actually seem to lead to a noticeable difference in overhead:
> > 
> >   From an aarch64 VM running on a MacBook M4:
> >     lock() when irq is disabled, 100 times cost Delta { nanos: 500
> > }
> >     lock_with() when irq is disabled, 100 times cost Delta { nanos:
> > 292 }
> >     lock() when irq is enabled, 100 times cost Delta { nanos: 834 }
> > 
> >     lock() when irq is disabled, 100 times cost Delta { nanos: 459
> > }
> >     lock_with() when irq is disabled, 100 times cost Delta { nanos:
> > 291 }
> >     lock() when irq is enabled, 100 times cost Delta { nanos: 709 }
> > 
> >   From an x86_64 VM (qemu/kvm) running on a i7-13700H
> >     lock() when irq is disabled, 100 times cost Delta { nanos: 1002
> > }
> >     lock_with() when irq is disabled, 100 times cost Delta { nanos:
> > 729 }
> >     lock() when irq is enabled, 100 times cost Delta { nanos: 1516
> > }
> > 
> >     lock() when irq is disabled, 100 times cost Delta { nanos: 754
> > }
> >     lock_with() when irq is disabled, 100 times cost Delta { nanos:
> > 966 }
> >     lock() when irq is enabled, 100 times cost Delta { nanos: 1227
> > }
> > 
> >     (note that there were some runs on x86_64 where lock() on irq
> > disabled
> >     vs. lock_with() on irq disabled had equivalent benchmarks, but
> > it very
> >     much appeared to be a minority of test runs.
> > 
> > While it's not clear how this affects real-world workloads yet,
> > let's add
> > this for the time being so we can find out.
> > 
> > This makes it so that a `SpinLockIrq` will work like a `SpinLock`
> > if
> > interrupts are disabled. So a function:
> > 
> >         (&'a SpinLockIrq, &'a InterruptDisabled) -> Guard<'a, ..,
> > SpinLockBackend>
> > 
> > makes sense. Note that due to `Guard` and `InterruptDisabled`
> > having the
> > same lifetime, interrupts cannot be enabled while the Guard exists.
> > 
> > Signed-off-by: Lyude Paul <lyude@redhat.com>
> > Co-developed-by: Boqun Feng <boqun.feng@gmail.com>
> > Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> > 
> > ---
> > This was originally two patches, but keeping them split didn't make
> > sense
> > after going from BackendInContext to BackendWithContext.
> > 
> > V10:
> > * Fix typos - Dirk/Lyude
> > * Since we're adding support for context locks to GlobalLock as
> > well, let's
> >   also make sure to cover try_lock while we're at it and add
> > try_lock_with
> > * Add a private function as_lock_in_context() for handling casting
> > from a
> >   Lock<T, B> to Lock<T, B::ContextualBackend> so we don't have to
> > duplicate
> >   safety comments
> > V11:
> > * Fix clippy::ref_as_ptr error in Lock::as_lock_in_context()
> > V14:
> > * Add benchmark results, rewrite commit message
> > V17:
> > * Introduce `BackendWithContext`, move context-related bits into
> > there and
> >   out of `Backend`.
> > * Add missing #[must_use = …] for try_lock_with()
> > * Remove all unsafe code from lock_with() and try_lock_with():
> >   Somehow I never noticed that literally none of the unsafe code in
> > these
> >   two functions is needed with as_lock_in_context()...
> > V18:
> > * Get rid of BackendWithContext
> > * Just use transmute in as_lock_in_context()
> > * Now that we're only supporting IRQ spinlocks and not using
> > traits, use
> >   the type aliases for SpinLock and SpinLockGuard
> > * Improve the docs now that we're not using traits.
> > 
> >  rust/kernel/sync/lock/spinlock.rs | 78
> > ++++++++++++++++++++++++++++++-
> >  1 file changed, 77 insertions(+), 1 deletion(-)
> > 
> > diff --git a/rust/kernel/sync/lock/spinlock.rs
> > b/rust/kernel/sync/lock/spinlock.rs
> > index f11a84505ba0e..de736cb777e93 100644
> > --- a/rust/kernel/sync/lock/spinlock.rs
> > +++ b/rust/kernel/sync/lock/spinlock.rs
> > @@ -4,7 +4,10 @@
> >  //!
> >  //! This module allows Rust code to use the kernel's `spinlock_t`.
> >  use super::*;
> > -use crate::prelude::*;
> > +use crate::{
> > +    interrupt::LocalInterruptDisabled,
> > +    prelude::*, //
> > +};
> >  
> >  /// Creates a [`SpinLock`] initialiser with the given name and a
> > newly-created lock class.
> >  ///
> > @@ -224,6 +227,45 @@ macro_rules! new_spinlock_irq {
> >  /// # Ok::<(), Error>(())
> >  /// ```
> >  ///
> > +/// The next example demonstrates locking a [`SpinLockIrq`] using
> > [`lock_with()`] in a function
> > +/// which can only be called when local processor interrupts are
> > already disabled.
> > +///
> > +/// ```
> > +/// use kernel::sync::{new_spinlock_irq, SpinLockIrq};
> > +/// use kernel::interrupt::*;
> > +///
> > +/// struct Inner {
> > +///     a: u32,
> > +/// }
> > +///
> > +/// #[pin_data]
> > +/// struct Example {
> > +///     #[pin]
> > +///     inner: SpinLockIrq<Inner>,
> > +/// }
> > +///
> > +/// impl Example {
> > +///     fn new() -> impl PinInit<Self> {
> > +///         pin_init!(Self {
> > +///             inner <- new_spinlock_irq!(Inner { a: 20 }),
> > +///         })
> > +///     }
> > +/// }
> > +///
> > +/// // Accessing an `Example` from a function that can only be
> > called in no-interrupt contexts.
> > +/// fn noirq_work(e: &Example, interrupt_disabled:
> > &LocalInterruptDisabled) {
> > +///     // Because we know interrupts are disabled from
> > interrupt_disable, we can skip toggling
> > +///     // interrupt state using lock_with() and the provided
> > token
> > +///     assert_eq!(e.inner.lock_with(interrupt_disabled).a, 20);
> > +/// }
> > +///
> > +/// # let e = KBox::pin_init(Example::new(), GFP_KERNEL)?;
> > +/// # let interrupt_guard = local_interrupt_disable();
> > +/// # noirq_work(&e, &interrupt_guard);
> > +/// #
> > +/// # Ok::<(), Error>(())
> > +/// ```
> > +///
> >  /// [`lock()`]: SpinLockIrq::lock
> >  /// [`lock_with()`]: SpinLockIrq::lock_with
> >  pub type SpinLockIrq<T> = super::Lock<T, SpinLockIrqBackend>;
> > @@ -286,6 +328,40 @@ unsafe fn assert_is_held(ptr: *mut
> > Self::State) {
> >      }
> >  }
> >  
> 
> This is much cleaner now compared the previous series. Thanks!
> 
> With functions marked as `#[inline]` as appropriate:
> 
>     Reviewed-by: Gary Guo <gary@garyguo.net>
> 
> BTW: do we want to have a
> 
>     impl<'a> lock::Guard<'a, T, SpinLockIrqBackend> {
>         fn as_local_irq_disabled(&self) -> &LocalInterruptDisabled;
>     }
> 

Yes imo - since it lets us get to the level of skipping assertions that
C is currently able to hit. Though, I wonder if this would be better
suited for AsRef?

I will save this for a follow-up patch though, since we're so close to
getting this in right now.

> ?
> 
> Best,
> Gary
> 
> > +impl<T: ?Sized> Lock<T, SpinLockIrqBackend> {
> > +    /// Casts the lock as a `Lock<T, SpinLockBackend>`.
> > +    fn as_lock_in_interrupt<'a>(&'a self, _context: &'a
> > LocalInterruptDisabled) -> &'a SpinLock<T> {
> > +        // SAFETY:
> > +        // - `Lock<T, SpinLockBackend>` and `Lock<T,
> > SpinLockIrqBackend>` both have identical data
> > +        //   layouts.
> > +        // - As long as local interrupts are disabled (which is
> > proven to be true by _context), it
> > +        //   is safe to treat a lock with SpinLockIrqBackend as a
> > SpinLockBackend lock.
> > +        unsafe { core::mem::transmute(self) }
> > +    }
> > +
> > +    /// Acquires the lock without modifying local interrupt state.
> > +    ///
> > +    /// This function should be used in place of the more
> > expensive [`Lock::lock()`] function when
> > +    /// possible for [`SpinLockIrq`] locks.
> > +    pub fn lock_with<'a>(&'a self, context: &'a
> > LocalInterruptDisabled) -> SpinLockGuard<'a, T> {
> > +        self.as_lock_in_interrupt(context).lock()
> > +    }
> > +
> > +    /// Tries to acquire the lock without modifying local
> > interrupt state.
> > +    ///
> > +    /// This function should be used in place of the more
> > expensive [`Lock::try_lock()`] function
> > +    /// when possible for [`SpinLockIrq`] locks.
> > +    ///
> > +    /// Returns a guard that can be used to access the data
> > protected by the lock if successful.
> > +    #[must_use = "if unused, the lock will be immediately
> > unlocked"]
> > +    pub fn try_lock_with<'a>(
> > +        &'a self,
> > +        context: &'a LocalInterruptDisabled,
> > +    ) -> Option<SpinLockGuard<'a, T>> {
> > +        self.as_lock_in_interrupt(context).try_lock()
> > +    }
> > +}
> > +
> >  #[kunit_tests(rust_spinlock_irq_condvar)]
> >  mod tests {
> >      use super::*;


      reply	other threads:[~2026-03-02 22:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-05 20:44 [PATCH v18 0/5] SpinLockIrq for rust Lyude Paul
2026-02-05 20:44 ` [PATCH v18 1/5] rust: Introduce interrupt module Lyude Paul
2026-02-05 23:13   ` Gary Guo
2026-02-05 20:44 ` [PATCH v18 2/5] rust: helper: Add spin_{un,}lock_irq_{enable,disable}() helpers Lyude Paul
2026-02-05 23:13   ` Gary Guo
2026-02-05 20:44 ` [PATCH v18 3/5] rust: sync: use super::* in spinlock.rs Lyude Paul
2026-02-05 20:44 ` [PATCH v18 4/5] rust: sync: Add SpinLockIrq Lyude Paul
2026-02-05 23:19   ` Gary Guo
2026-02-05 20:44 ` [PATCH v18 5/5] rust: sync: Introduce SpinLockIrq::lock_with() and friends Lyude Paul
2026-02-05 23:23   ` Gary Guo
2026-03-02 22:47     ` lyude [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=482ef57154db2d58e1907a1648816ee31f2045a2.camel@redhat.com \
    --to=lyude@redhat.com \
    --cc=a.hindborg@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=lossin@kernel.org \
    --cc=mingo@redhat.com \
    --cc=ojeda@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tmgross@umich.edu \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®