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

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

[Luigi Rizzo]

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 ?

static int apic_retrigger_irq(struct irq_data *irqd)
{
        struct apic_chip_data *apicd = apic_chip_data(irqd);
        unsigned long flags;

        raw_spin_lock_irqsave(&vector_lock, flags);
        __apic_send_IPI(apicd->cpu, apicd->vector);
        raw_spin_unlock_irqrestore(&vector_lock, flags);

        return 1;
}

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

[Thomas Gleixner]

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.

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

[Thomas Gleixner]

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?

Thanks,

        tglx

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

[Luigi Rizzo]

On Wed, Feb 18, 2026 at 9:49 PM Thomas Gleixner <tglx@linutronix.de> 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