lkml.org 
[lkml]   [1999]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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