Messages in this thread | | | Date | Thu, 11 Nov 1999 11:22:38 +0100 (MET) | From | Roman Zippel <> | Subject | Re: linux interrupt handling problem |
| |
Hi,
On Wed, 10 Nov 1999 yodaiken@chelm.cs.nmt.edu wrote:
> On Wed, Nov 10, 1999 at 11:30:53AM +0100, Roman Zippel wrote: > > That's a problem I would like to address later, since it's a perfomance > > only problem, where the sti() stuff is also a portability problem. > > Anyway, I'm preparing some stuff to address this, but that's the more > > complex change, but I hope to get a better overall perfomance out of > > this, as there are more perfomance problems with some linux interrupt > > handler (especially almost all block devices). > > Any measurements to show that this is a real problem?
Not yet, I'm still working on this.
> My intuition > is that the simple Linux model has enormous advantages over > more complex schemes.
Since the smp support it's not simple anymore anyway. The current ide problems show that.
> For one thing, using irq levels makes it > very easy to introduce impossible to find synchronization bugs. > Down in the interior of the scsi code, someone uses the wrong irq > level and the serial driver starts dropping bytes every now and > then. For another, RTLinux depends on a Linux to have a sensible > and clear interrupt model. I very much doubt we could have > made RTLinux work if Linux was trying to be too clever about > interrupt priorities etc.
I don't want that drivers know about interrupt levels, I want it even simpler, they should basically assume nothing about specific interrupt behavivour and interrupt tuning shouldn't happen within the driver, except of hints to the interrupt system.
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/
| |