2

Is it possible to run multiple instances of a same interrupt simultaneously on a multi processor system in linux? If not possible, why do we need to synchronize between interrupt handlers using spin locks?

Thanks Venkatesh

venkateshpnv
  • 41
  • 2

2 Answers2

2

On a SMP architecture Advanced Programmable Interrupt Controller(APIC) is used to route the interrupts from peripherals to the CPU's.

the APIC, based on
1. the routing table (where interrupt affinity is set to a particular processor),
2. priority of the interrupt,
3. the load on the CPU's

For example, consider a interrupt is received at IRQ line 32, this goes through APIC,the interrupt is routed to a particular CPU, for now consider CPU0, this interrupt line is masked until the ISR is handled, which means you will not get a interrupt of the same type if ISR execution is in progress

Once ISR is handled, only then the interrupt line is unmasked for future interrupts

Santosh A
  • 5,173
  • 27
  • 37
1

Is it possible to run multiple instances of a same interrupt simultaneously on a multi processor system in linux?

The interrupt handlers are generally serialized. Meaning, that only one instance of the handler would be running(on either of the processors). While this is running, if same type of interrupt is again generated, it is processed only after the current one is done, thus serialized. While "this" handler is being executed by one of the core, other core might service handler of a different instance.

Why do we need to synchronize between interrupt handlers using spin locks?

The spinlocks are used even in such cases as the data has to be protected against some other threads(for example bottom halved, user read/write handler functions, etc). The scenario could be something like this :

my_ISR()
{
    lock(&l);
    // data is accessed here
    unlock(&l);    
}

my_other_thread()
{
    lock(&l);
    // same data is accessed here
    unlock(&l);
}
raghav3276
  • 1,088
  • 8
  • 14
  • 1
    From the book "Essentials of device drivers by Sreekrishnan Venkateswaran", " You need not design interrupt handlers to be reentrant. When an interrupt handler is running, the corresponding IRQ is disabled until the handler returns. So, unlike process context code, different instances of the same handler will not run simultaneously on multiple processors. " From above statement, is it possible to handle another interrupt by any core while one core is already executing the handler for that interrupt? If there's no second instance of interrupt handler running, then why do we need spinlocks? – venkateshpnv Aug 06 '14 at 16:27
  • The corresponding IRQ "on the current processor" is disabled. The APIC may still drive the IRQ to the other core. Yes, it is possible to handle another interrupt by any core while this core is processing your interrupt. As I've already mentioned, even though same instances might not run together, there is a possible chance of sharing the data with other threads like the bottom halves, for example(which might run on other core parallel to the handler). – raghav3276 Aug 07 '14 at 04:16
  • @raghav3276 So if you say another interrupt can be handled in any other core apart from the already being serviced interrupt, does it mean each ISR(top halve) corresponding to an interrupt is run parallel as a separate kernel thread in each of their allotted cores? I am speaking only about the top halves here. So when the APIC drives the second IRQ, the kernel will spwan a new kernel thread/process to run its corresponding ISR on a not already occupied core. – Shyam Jan 18 '18 at 01:19