lkml.org 
[lkml]   [2000]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: new IRQ scalability changes in 2.3.48
Hi,

> > Is it now an error to do __sti in interrupt mode?
>
> No, why would it be?
>
> Doing an __sti in interrupts will let higher-priority interrupts in. As it
> always has.
>
> 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).

Could we then _please_ call it differently to make it visible that
something is wrong. The IDE code has already a ide__sti because of the
problems it causes on other architectures. We should not carelessly allow
generally what is no problem on other hardware. You get lots of hardware
(especially embedded ones) into trouble, if you _easily_ allow a __sti in
an interrupt.
To explain the problem a bit more in detail: basically you have only three
possibilities to avoid interrupts going mad:
- local interrupt mask in the cpu
- interrupt mask in the interrupt controller
- acknowledge interrupt and manage a pending bit.
Now there are systems out there, that don't have an interrupt controller
and consequently it's possible the interrupt has to be acknowledge (e.g.
the interrupt is level sensitive and the driver has to remove the cause of
the interrupt), so if you now allow other interrupts to do a __sti, what
shall I do now?
There are some more (cpu dependend) tricks (like playing with the
interrupt stack), but all this causes suffering in the general case for a
few special cases, what could so easily avoided.
Of course I could make __sti() conditional, but the IDE interrupt again
starts with a __cli(). So what I'm arguing for is, please don't advertise
__sti() for hiding a broken design, make it _visible_.

bye, Roman


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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