>>
>> While it is completely valid to share interrupts, it is in general not
>> recommended with hardware that will be using heavy interrupts.

> Pardon my ignorance... what kind of interrupts are "heavy interrupts"?

Perhaps those either whose frequency of occurence is very high, or the ones that need a lot of work to be done in the 
ISR ...
 
Thanks,
 
Rajat

" But many drivers don't; they schedule their thread-level event
handlers to check their hardware, which is inefficient and reduces
performance."

That is the important line right there.  Sharing interrupts works great,
but if you have a frequent interrupt source sharing with a driver that
schedules a thread to check the hardware, the overhead of scheduling the
thread becomes noticeable.

David

> -----Original Message-----
> From: Steve Reid [mailto:stever@qnx.com] 
> Sent: July 21, 2008 10:47 AM
> To: ostech-core_os
> Subject: Re: Sharing interrupts
> 
> Here's some more information from the Core Networking docs. 
> Does it apply in general?
> 
> Having different devices sharing a hardware interrupt is kind 
> of a neat idea, but unless you really need to do it - because 
> you've run out of hardware interrupt lines - it generally 
> doesn't help you much. In fact, it can cause you trouble. For 
> example, if your driver doesn't work (e.g. no received 
> packets), check to see if it's sharing an interrupt with 
> another device, and if so, reconfigure your board so it doesn't.
> 
> Most of the time, when shared interrupts are configured, 
> there's no good reason for it (i.e. you haven't really run 
> out of interrupts) and this can decrease your performance, 
> because when the interrupt fires, all of the devices sharing 
> the interrupt need to run and check to see if it's for them. 
> If you check the source code, you can see that some drivers 
> do the "right thing," which is to read registers in their 
> interrupt handlers to see if the interrupt is really for 
> them, and then ignore it if not. But many drivers don't; they 
> schedule their thread-level event handlers to check their 
> hardware, which is inefficient and reduces performance.
> 
> If you're using the PCI bus, use the pci -v utility to check 
> the interrupt allocation.
> 
> Sharing interrupts can vastly increase interrupt latency, 
> depending upon exactly what each of the drivers do. After an 
> interrupt fires, the kernel doesn't reenable it until all 
> driver handlers tell the kernel that they've finished 
> handling it. So, if one driver takes a long time servicing a 
> shared interrupt that's masked, then if another device on the 
> same interrupt causes an interrupt during that time period, 
> processing of that interrupt can be delayed for an unknown 
> duration of time.
> 
> Interrupt sharing can cause problems, and reduce performance, 
> increase CPU consumption, and seriously increase latency. 
> Unless you really need to do it, don't. If you must share 
> interrupts, make sure your drivers are doing the "right thing." 
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post10803
>