[lkml]   [2000]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: new IRQ scalability changes in 2.3.48
On Sun, Mar 12, 2000 at 09:53:29AM -0800, Linus Torvalds wrote:
> Doing an __sti in interrupts will let higher-priority interrupts in. As it
> always has.

Previously, _any_ interrupt was let to progress. That is, hardware
priorities were ignored by Linux.

> I think it's probably stupid most of the time, and shows that something is
> wrong (an interrupt should not take long enough for it to matter that we
> do an __sti), but sometimes that kind of stupidity is a result of horrible
> hardware latencies (eg the time it takes to read a sector from the IDE
> disk using programmed IO).

So if we have a hardware determined higher priority level IDE than level
network, then it previously was the case that if the IDE driver was polite
and did an __sti, the network was assured of a relatively low latency. However,
the network now may need to wait until the programmed i/o completes.
Probably programmed i/o should rather happen in soft_interrupt space, but
with the current drivers it does not.

> Quite regardless of how you do interrupts: it doesn't matter where youput
> the ACK's, you always need to make sure that irq masking etc is correct,
> and you must NOT allow a context switch while an interrupt handler is
> still running.

Ok. Ingo: does your "low latency" patch violate this rule?

> You're making these problems up.

Yes. I thought that the hardware worked like 8259s, but it is somewhat
more sensible.

> > I really dislike hardware interrupt priorities since they have nothing
> > to do with the OS' ideas of importance and are complex to work with.
> I agree. I think interrupt controllers should be simple masks, nothing
> more, nothing less.
> However, I'm not designing the hardware.

It's amazing how stubbornly hardware folks refuse to consider OS in their

Victor Yodaiken
FSMLabs is a servicemark and a service of
VJY Associates L.L.C, New Mexico.

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

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