Linked by Hadrien Grasland on Thu 19th May 2011 21:31 UTC
Hardware, Embedded Systems Having read the feedback resulting from my previous post on interrupts (itself resulting from an earlier OSnews Asks item on the subject), I've had a look at the way interrupts work on PowerPC v2.02, SPARC v9, Alpha and IA-64 (Itanium), and contribute this back to anyone who's interested (or willing to report any blatant flaw found in my posts). I've also tried to rework a bit my interrupt handling model to make it significantly clearer and have it look more like a design doc and less like a code draft.
Thread beginning with comment 474150
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Pop-up threads
by Neolander on Sat 21st May 2011 20:11 UTC in reply to "RE[4]: Pop-up threads"
Member since:

Consider an async model on a single processor. Now multiply that by X processors running X async handlers.
Now, you can map each device to raise interrupts on a specific CPU, also give the driver affinity to that CPU. Now when an interrupt for the device occurs, the driver can safely assume an async model for all internal resources without any synchronization.
Assuming the devices are well distributed (statically) between CPUs, then they'll be serviced in parallel.

The requirement to route the IRQs to a specific CPU may not be strictly necessary, but it simplifies the example and reduces latency caused by transferring the request. This could even be true for a threaded model?

Yup, I can't see a reason why processing IRQs on different processors couldn't just as well be done with a threaded model. The problem will be to balance the IRQ load fairly across all processors, I think. Some IRQs fire very frequently (clock), some never happen (MachineCheck), but many interrupts happen frequently at a moment and then stop happening for minutes or hours. As a silly example, sound card interrupts (buffer is full/empty) only occur when you play or record sound.

Well, there's no denying that last point. Unless you allow userspace threads which don't require a syscall?

Well, it's not as if I could forbid them ^^ But looking at Tanenbaum's book (my OS development bible), they seem to have several issues. Like, you know, the fact that you cannot use clock interrupts to distribute time fairly across them, or the fact that if an userspace thread blocks for I/O, all other userspace thread are blocked for I/O at the same time, since it's the same thread from the kernel's point of view.

You hit some good points further down, but I'm so tired...I'd better not tackle them today.

I'd be happy to read this ;) In meantime, I've done my homework too : here's a seriously written, in-depth explanation of why I use a microkernel, RPC as the main IPC method, etc, ending with a discussion of threaded model and asynchronous model based on our points in these comments, if you want to have a look...

Edited 2011-05-21 20:13 UTC

Reply Parent Score: 1