Re: [PATCH][RFC] per isr in_progress markers

From: Linus Torvalds (torvalds@transmeta.com)
Date: Sun Sep 08 2002 - 17:01:02 EST


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