IRQ Dispatcher Design critique request

[gravaera]

Hi all:

I've found that in trying to ensure that I speed up syscalls as much as possible, I've been trying to research how intensively/often IRQs and exceptions can occur on a machine, especially one with a good few pieces of hardware, like a PC.

I have a two questions with regards to design, and general clarification:

I have decided to have my IRQ Dispatching be multithreaded. That is, take the example of process A running on CPU0. Process A would have a timeslice of N units of 'time' based on the timer IRQs or the Local timer interrupt. I find that I hate the idea of installing IRQ handlers on interrupt vectors:

A rundown on my approach to handling vectoring and IRQ/vector sharing: On any architecture, there is a table of vectors which the CPU would index into. From here the CPU would jump into a routine provided by the OS, or be manually directed to do so. I have designed everything such that the routines which are jumped to would of course merge at a common entry point after, as is conventional, pushing an Interrupt number onto the stack.

The common entry point would now, barring other necessary things, now look into a linked list of exception handlers and execute these in sequence. (I have a question which would logically branch from here, which I'll ask later on.).

In the linked list for each vector, (ignoring the syscall vector) there is a routine which adds the vector number itself to a separate list, and then continues processing the exception handlers. The idea is that I wish to isolate IRQ handling from exception handling when the a process is interrupted so that the process is given its optimum performance time, and best response time, although the Interrupt Response Time would be increased.

The vector number, after being added to the list, is now processed in a FIFO method, by a separate thread which runs in the kernel's upper address space. The thread picks up the vector number at the front of the queue, and NOW, it consults a linked list of IRQ handlers, and runs the ISRs for the various hardware components which share that vector, and like the Windows IRQ handling method, (http://msdn.microsoft.com/en-us/library/ms901812.aspx), each ISR returns a thread number which tells the kernel which Driver userspace process must be scheduled to handle the IRQ fully, after the ISR does the initial work to acknowledge the device and cause it to stop asserting the IRQ line.

For for a process A, running on a CPU 0, the maximum amount of time required for it to wait between IRQs or exceptions is the time required for the kernel to test which exception was generated (if any), and execute code to handle the exception and return to the process, while passing a vector number to another thread which will test to see, during ITS OWN execution timeslice, which IRQ had occured, and execute the ISRs for the IRQ on its own timeslice. The process/thread is therefore given the smallest amount of wait time reasonable possible for any interrupt other than a SWI.

Does this sound logical? Or is the time between the generation of an IRQ and the beginning of the execution of an ISR for that IRQ too much to be justifiable?

Also, for the second question which I had hinted at earlier:

I find that no matter how far I read into the Linux kernel documentation, or even what scraps I can find from Windows' internals, I always find that documentation speaks of IRQ sharing in the sense of actually switching the routine installed on the actual hardware vector table, rather than simply holding a linked list of handlers installed on the IRQ and iterating through them. Yet I find switching the vector handler routine to be almost ridiculous (bar the speed gain), and the linked list method imho, allows for true vector sharing.

In linux it seems, based on two long dreary articles I've read, that devices can actually selfishly request for sole access to a vector, by not setting a particular flag when requesting to be installed on a particular vector. I don't see why any kernel would even allow this, since it doesn't make any sense for the kernel to allow any device to monopolize a vector: what about other devices wanting to use it?

So the second question is: Is it logical to ignore what seems to be the convention on Linux and Windows and use a linked list? Or does someone who follows Linux know why they like to switch routines in vectors? And would anyone know why any kernel would allow a device to actually ask for exclusive access to a vector? (http://www.makelinux.net/ldd3/chp-10-sect-5.shtml)

--All the best,
gravaera.

[nedbrek]

I haven't written any device drivers, so take this with a grain (or truckload) of salt...

Reading chapter 10 from your link leads me to a few conclusions:
1) There is a sort of trust between the kernel and the driver, the user trusts the driver to make the hardware work
2) Some hardware is just finicky, and will not share the IRQ
3) The driver is the only one who can know how the hardware behaves - that's the whole point of the driver, to make the hw work.
4) The driver is encouraged to use shared mode, if the hw supports it
5) The driver is encouraged to use the IRQ for the minimum amount of time actually required to get everything done - thus allowing the line to be used by someone else

[gravaera]

Hi:

Thanks to all those who read this, and to nedbrek; I suppose I could take this to mean that at least at the more experienced members found no hiccups in the design I presented; That's great

--Thanks for your time,
gravaera

[Combuster]

Probably the idea of changing the vector number, is that it is more likely that the device that last triggered the interrupt also triggered this interrupt (assuming it's on the same line). It's therefore more efficient to only run the first handler, and have it return if the device in question actually had an interrupt, and not to process the other ISRs if the IRQ was handled. If there are multiple IRQs, the interrupt will fire again, and the first handler will tell you that it wasnt him, so you can go on and ask the next one.