Re: [QUESTION] is vector_lock needed in apic_retrigger_irq() ?

[Luigi Rizzo]

On Wed, Feb 18, 2026 at 9:49 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>
> On Tue, Feb 17 2026 at 22:08, Thomas Gleixner wrote:
> > On Mon, Feb 16 2026 at 21:44, Luigi Rizzo wrote:
> >> apic_retrigger_irq() grabs vector_lock, see code below.
> >>
> >> I am not sure if this is needed, because the function
> >> is called with a lock held on irqdesc, so I think the CPU and
> >> vector should be stable.
> >>
> >> Comments ?
> >
> > You're right. Any action which would change apcid->vector has to hold
> > the descriptor lock.
>
> I did some archaeology. This is a leftover from the v2.6 times where it
> was truly required. That never got cleaned up after the whole vector
> management got rewritten and the reason for the locking went away in
> v4.15. Nobody noticed :)
>
> How did you find that?

perf showed high lock contention while stress testing moderation with 12SSD
(96 vectors and a total of 20 MIOPs).  Then it was just a matter of
understanding
whether that global lock was really needed.

As for why my test caused high contention:
NVME does not self disable interrupts, unlike NICs, so by the time the
handler runs
there is a high probability that another interrupt has arrived,
requiring a reinject.
When moderation timers fire (they are independent, but  probably they end up
being relatively close in time) all these reinject are called close to
each other.

cheers
luigi