David Sarrazin
07/21/2008 2:45 PM
post10823
|
" 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
>
|
|
|