Interrupt handling

[Bruce Rowen]

On Feb 16, 2011, at 9:49 PM, Darshan Ghumare wrote:

> Sir,
>
> Thank you very much for the explanation.
>
> On Wed, Feb 16, 2011 at 8:20 PM, Bruce Rowen <browen at aoc.nrao.edu>  
> wrote:
> When the interrupt line is asserted by the hardware device (could be
> a  peripheral, whatever) the interrupt controller decides how to pass
> this signal onto the processor. Some controllers will prioritize the
> interrupt based on the interrupt line number. For example, assume line
> #3 has interrupted. If line #4 then interrupts and #4 has higher
> priority, the service routine for interrupt line #3 will itself be
> interrupted. If a lower priority interrupt (say #2) occurs, then #3
> will continue until completion at which point #2 will be serviced.
> Note that this hardware prioritization is highly dependent on hardware
> and hardware setup. It could be such that an incoming interrupt with a
> lower priority than a currently servicing interrupt is simply ignored.
>
> If that is the case,
> 1) What happens in the case of x86?

Depends on the interrupt controller. Common systems have interrupt  
controllers embedded into 'glue' chips such as a 'Southbridge' or  
'Northbridge'.
To find the exact device and functionality you will need to consult  
the hardware manuals for your system.

> 2) Can we configure hardware (say, I/O APIC) so that alway higher  
> priority interrupt's handler runs first?

My experience with small form-factor (pc104) X86 is that much of the  
setup/assignments of priority is done in the BIOS. I found it to be  
complex to change the assignments after the kernel is running so your  
best chance is to use the features of your BIOS.

Remember that the ISR typically exists as only a handful of lines of  
code. Its job is to determine that its hardware was the one  
interrupting (for when hardware shares interrupt lines), do whatever  
hardware changes are required (clear interrupt flags, acknowledge DMA,  
etc.), and then tell the kernel to schedule the rest of the handler  
(tasklet/bottom half, etc.).
A truly prioritized interrupt would allow the higher level interrupt  
to preempt the running of a lower levels ISR and tasklet. A lower  
level interrupt would be held off until the higher level interrupts  
ISR has completed, but it then could preempt the running of the higher  
level interrupts tasklet.
Once all interrupts are scheduled to run as tasklets, it is the order  
they are queued that determines their run order (last in, first run).

For example, scheduling the tasklet for a higher level interrupt with  
tasklet_hi_schedule() will allow it to run before those scheduled with  
tasklet_schedule().

Thus there are two places to control interrupt servicing priorities.  
The hardware level which allows preemption during the microseconds  
long hardware ISR code, and the software (tasklet) level that has  
priorities assigned by scheduling methods and scheduling order.

-Bruce





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110217/39c6b579/attachment.html