On Sun, 8 Sep 2002, Zwane Mwaikambo wrote:
>
> Here is a newer (untested) patch incorporating Ingo's suggestions as well
> as adding an extra request_irq flag so that isrs can use isr_unmask_irq()
> to enable their interrupt lines.
Hmm.. I really don't get the point of what this is supposed to actually
help.
Clearly, if the device doesn't share the irq line, this doesn't matter.
Similarly, it shouldn't matter if there is just one device that is active
(ie irq line sharing with some slow device where the interrupt happens
fairly seldom).
As far as I can tell, the only time when this might be an advantage is an
SMP machine with multiple devices sharing an extremely busy irq line. Then
the per-isr in-progress bit allows multiple CPU's to actively handle
several of the devices at the same time.
Or is there some other case where this is helpful?
The reason I don't much like this is:
- bigger SMP machines don't tend to share all that many interrupts
anyway, since they all use IO-APICs and tend to have fairly sparse irq
setups (as opposed to most laptops, which often seem to put every PCI
device on the same irq)
- if both devices really _are_ that actively pushing a lot of interrupts,
it sounds like you actually want to keep the caches hot on one CPU
instead of randomly taking the irq on various CPU's. Have you actually
got performance numbers to show otherwise? That irq lock is going to
bounce back and forth a _lot_, quite possibly undoing any advantage of
the patch.
- on all the cases where this _doesn't_ help, it just potentially makes
the stack depth even deeper.
So I'd really like to understand what the upsides are..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:15 EST