--- Pavel Cahyna <pcah8322@artax.karlin.mff.cuni.cz> wrote: > Hello,
> 
> I came across this paper, which may be interesting for NetBSD too:
> 
> "Running and tuning OpenBSD network servers in a production
> environment"
> 
> (http://openbsd.underlinux.com.br/papers/tuning.pdf)
> 
> In section "IRQ" there is an interesting claim that sharing
> interrupts
> between netwok cards could improve performance. (I would think the
> opposite is true.) Quoting the paragraph for your convenience:
> 
> "Every interrupt requires a context switch, from
> the process running when the IRQ took place,
> to the interrupt handler. As a number of things
> must be done upon entering the interrupt han-
> dler, a large quantity of interrupts can result
> in excess time required for context switching.
> One non-obvious way to reduce this load is to
> share interrupts between the network adapters,
> something permitted on the PCI bus. As many
> people are not even aware of the the possibility
> of interrupt sharing, and the benefits are not
> obvious, let's look at this a little closer.
> 
> With separate adapters on separate interrupt
> lines, when the first interrupt comes in, a con-
> text switch to the interrupt handler takes place.
> If another interrupt comes in from the other
> adapter while the first interrupt is still being
> handled, it will either interrupt the first han-
> dler, or be delayed until the first handler has
> completed, depending on priority, but regard-
> less, two additional context switches will take
> place { one into the second handler, one back
> out.
> 
> In the case of the PCI and EISA busses, in-
> terrupts are level triggered, not edge triggered,
> which makes interrupt sharing possible. As
> long as the interrupt line is held active, a device
> needs servicing, even if the first device which
> triggered the interrupt has already been ser-
> viced. So, in this case, when the first adapter
> triggers the interrupt, there will be a context
> switch to the handler. Before the handler re-
> turns, it will see if any other devices need ser-
> vicing, before doing a context switch back to
> the previous process.
> 
> In a busy environment, when many devices are
> needing service, saving these context switches
> can signicantly improve performance by per-
> mitting the processor to spend more time pro-
> cessing data, rather than switching between
> tasks.  (...) "
> 
> Now, a couple of questions:
> 
> - Is this true for NetBSD too?
> 
> - Isn't this a symptom of bad design? If there are different
> interrupt
>   lines for different devices, the interrupt handler can immediately
>   see which device caused the interrupt. If two devices share the
> same
>   interrupt, the interrupt code must first look which device caused
> it.
>   I would also guess that with different interrupts, it could be
>   easier to run two interrupt handlers concurrently on two
> processors.
>   What's exactly the situation with this?
> 
> Thanks	Pavel
>  

On your last statement ("...it could be easier to run two interrupt
handlers concurrently on two processors."): I do not think NetBSD has a
threaded or reentrant kernel. Thus, it is currently impossible to
handle interrupts concurrently in SMP on NetBSD. Considering this, it
seems like this part of the analysis is valid in the case of Net/Open
and possible FreeBSD.

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca