[haiku-development] Re: Free irq
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 16 Oct 2011 17:41:06 +0200
Don Quixote de la Mancha <quixote@xxxxxxxxxxxxxxxx> wrote:
> It seems to me that better I/O throughput as well as latency could be
> obtained by maintaining some statistics on how many interrupts each
> device generates, as well as how long its primary interrupt handler
> takes to complete.
>
> Then one could, in principle, do some automated load balancing by
> placing frequently-interrupting or more important devices on their
> own
> interrupt, while the devices that either don't interrupt so often, or
> have very fast interrupt handlers get to share their interrupts.
>
> If you think this is a good idea, I will file a feature request in
> Trac.
While this is all nice in principle, it simply doesn't work for the
platform we target. Configurable interrupt lines are less common than
one would think. They need an interrupt link device that can be
programmed, hence they are more complex to implement than simply hooking
up one line to one input on the interrupt controller. They are
certainly found on higher end systems (and servers) where that
throughput may be more critical, but from looking through a lot of
syslogs, most systems simply have the 4 PCI interrupt lines connected
to 4 inputs on the IO-APIC and usually have built in (chipset) devices
hooked on seperate lines, most often still shared. You can't do
anything about the sharing in that case, because you simply can't
configure the lines used, they are physically hardwired. On servers,
there usually simply are multiple IO-APICs and then the different
devices are routed in a way that, while still hardwired, sharing is
reduced to a minimum.
Then there are the message signaled interrupts, which most new hardware
supports (and as it is mandated by PCI-Express, has to support). They
don't actually use hardware connections anymore and instead are done
fully in software and are, also under Haiku, allocated in a way that
they are not shared.
So basically there are only rather few systems that could profit from
such functionality and I would consider it of low priority, seeing that
most new hardware will avoid that problem by simply using message
signaled interrupts. Instead we should make sure that drivers that
could but currently don't use MSIs get updated. The FreeBSD
compatibility layer we have for network drivers already supports MSIs
and makes use of them under Haiku. Also, where possible, the link
devices are already configured in a way that they avoid sharing BTW.
A rather simple optimization to the interrupt handler that could be
done however, would be to reorder the installed interrupt handler list
so that handlers who service the most interrupts end up at the top of
the list (this only applies where multiple interrupt handlers are
installed of course). This would reduce the average interrupt handling
latency by avoiding to call into the handler routine of drivers that
only receive interrupts more rarely.
Regards
Michael
Other related posts:
