Messages in this thread | | | Date | Tue, 14 Mar 2000 10:28:02 +0100 (MET) | From | Roman Zippel <> | Subject | Re: 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/
| |