[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251016081513.GB3289052@noisy.programming.kicks-ass.net>
Date: Thu, 16 Oct 2025 10:15:13 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Bart Van Assche <bvanassche@....org>
Cc: Lyude Paul <lyude@...hat.com>, rust-for-linux@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
Boqun Feng <boqun.feng@...il.com>, linux-kernel@...r.kernel.org,
Daniel Almeida <daniel.almeida@...labora.com>,
Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Valentin Schneider <vschneid@...hat.com>,
Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.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>,
David Woodhouse <dwmw@...zon.co.uk>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Joel Fernandes <joelagnelf@...dia.com>,
Ryo Takakura <ryotkkr98@...il.com>,
K Prateek Nayak <kprateek.nayak@....com>
Subject: Re: [PATCH v13 05/17] irq & spin_lock: Add counted interrupt
disabling/enabling
On Wed, Oct 15, 2025 at 01:54:05PM -0700, Bart Van Assche wrote:
> > This also makes the wrapper of interrupt-disabling locks on Rust easier
> > to design.
>
> Is a new counter really required to fix the issues that exist in the
> above examples? Has it been considered to remove the spin_lock_irqsave()
> and spin_lock_irqrestore() definitions, to introduce a macro that saves
> the interrupt state in a local variable and restores the interrupt state
> from the same local variable? With this new macro, the first two examples
> above would be changed into the following (this code has not been tested
> in any way):
So the thing is that actually frobbing the hardware interrupt state is
relatively expensive. On x86 things like PUSHF/POPF/CLI/STI are
definitely on the 'nice to avoid' side of things.
Various people have written patches to avoid them on x86, and while none
of them have made it, they did show benefit (notably PowerPC already
does something tricky because for them it is *really* expensive).
So in that regard, keeping this counter allows us to strictly reduce the
places where we have to touch IF. The interface is nicer too, so a win
all-round.
My main objection to all this has been that they add to the interface
instead of replace the interface. Ideally this would implement
spin_lock_irq() and spin_lock_irqsave() in terms of the new
spin_lock_irq_disable() and then we go do tree wide cleanups over a few
cycles.
The problem is that that requires non-trivial per architecture work and
they've so far tried to avoid this...
Powered by blists - more mailing lists