How do interrupts work in multi-core system?

4
votes

I want to write code for interrupts of the buttons on Raspberry pi 2. This board uses QUAD Core Broadcom BCM2836 CPU (ARM architecture). That mean, only one CPU is on this board( Raspberry pi 2 ). But I don't know how do interrupts in multi-core system. I wonder whether interrupt line is connected to each core or one CPU. So, I found the paragraph below via Google.

Interrupts on multi-core systems On a multi-core system, each interrupt is directed to one (and only one) CPU, although it doesn't matter which. How this happens is under control of the programmable interrupt controller chip(s) on the board. When you initialize the PICs in your system's startup, you can program them to deliver the interrupts to whichever CPU you want to; on some PICs you can even get the interrupt to rotate between the CPUs each time it goes off.

Is this mean that interrupts happen with each CPU ? I can't understand exactly above info. If interrupts happen to each core, I must take account of critical section for shared data on each interrupt service routine of the buttons.

If interrupts happen to each CPU, I don't have to take account of critical section for shared data. What is correct?

To sum up, I wonder How do interrupts in multi-core system? Is the interrupt line is connected to each core or CPU? So, should I have to take account of critical section for same interrupt?

1
armraspberry-picpuinterrupt
have you checked? stackoverflow.com/questions/11811276/… – HRgiger
In short; "depends what the interrupt controller is capable of, and how you set it up". IIRC the interrupt controller on the 2836 is a bit 'special'. – Notlikethat
Possible duplicate of Interrupt handling on an SMP ARM system with a GIC; the question deals with Linux specifically, but the answer is not dependant on that. – artless noise
@artlessnoise If the 2836 had a GIC, Eric Anholt wouldn't be doing all of this ;) – Notlikethat
@Notlikethat Okay, but how is that conceptually different? The BCM code is in the main line. Register like LOCAL_TIMER, etc are per-cpu and the others are global. The chip doesn't appear to be as flexible as the GIC. The first to 'ACK' is the one to service and others get a spurious (if service attempt happen on other CPUs and there are no other interrupts) with interrupts routed globally with the GIC. – artless noise

1 Answers

2
votes

your quote from google looks quite generic or perhaps even leaning on the size of x86, but doesnt really matter if that were the case.

I sure hope that you would be able to control interrupts per cpu such that you can have one type go to one and another to another.

Likewise that there is a choice to have all of them interrupted in case you want that.

Interrupts are irrelevant to shared resources, you have to handle shared resources whether you are in an ISR or not, so the interrupt doesnt matter you have to deal with it. Having the ability to isolate interrupts from one peripheral to one cpu could make the sharing easier in that you could have one cpu own a resource and other cpus make requests to the cpu that owns it for example.

Dual, Quad, etc cores doesnt matter, treat each core as a single cpu, which it is, and solve the interrupt problems as you would for a single cpu. Again shared resources are shared resources, during interrupts or not during interrupts. Solve the problem for one cpu then deal with any sharing.

Being an ARM each chip vendors implementation can vary from another, so there cannot be one universal answer, you have to read the arm docs for the arm core (and if possible the specific version as they can/do vary) as well as the chip vendors docs for whatever they have around the arm core. Being a Broadcom in this case, good luck with chip vendor docs. They are at best limited, esp with the raspi2. You might have to dig through the linux sources. No matter what, arm, x86, mips, etc, you have to just read the documentation and do some experiments. Start off by treating each core as a standalone cpu, then deal with sharing of resources if required.

If I remember right the default case is to have just the first core running the kernel7.img off the sd card, the other three are spinning in a loop waiting for an address (each has its own) to be written to get them to jump to that and start doing something else. So you quite literally can just start off with a single cpu, no sharing, and figure that out, if you choose to not have code on the other cpus that touch that resource, done. if you do THEN figure out how to share a resource.