[lkml]   [2002]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH][RFC] per isr in_progress markers

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

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..


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.107 / U:1.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site