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

On Mon, 9 Sep 2002, Ingo Molnar wrote:
> On Sun, 8 Sep 2002, Linus Torvalds wrote:
> > 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?
> it could also improve latency of a faster interrupt source that shares its
> irq line with a slow (but still frequent) handler. (such as SCSI or ne2k.)

Well, it migth also _deprove_ that latency, as taking another interrupt is
a lot more expensive than just walking the list of ISR's on the existing
irq chain.

Particularly on a P4, taking an interrupt is quite expensive.

Remember: you'd be "improving latency" by taking several interrupts
instead of taking just one. And usually, if the system is really under so
much interrupt load that this would be noticeable, you want to try to
_mitigate_ interrupts instead of adding new ones.

I think. I'd like to point out that I just have a gut feel for this, so
I'm definitely not trying to say that I absolutely hate the idea and that
it will never happen. But the thing worries me a bit, and I really would
prefer to have some quantifiable reasons for or against it.

In other words, I kind of understand your concerns, but I've got concerns
of my own. But nobody will argue against numbers..


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:22    [W:0.106 / U:15.720 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site