Re: [PATCH 1/3] Separate IRQ-stacks from 4K-stacks option

[Lee Revell <rlrevell@joe-job.com>]

On Sun, 2004-09-12 at 11:45, Zwane Mwaikambo wrote:
> yOn Sun, 12 Sep 2004, Martin J. Bligh wrote:
> 
> > --Andrea Arcangeli <andrea@novell.com> wrote (on Sunday, September 12, 2004 16:17:01 +0200):
> > 
> > > On Fri, Sep 10, 2004 at 05:34:21PM +0200, Arjan van de Ven wrote:
> > >> disabling is actually not a bad idea; hard irq handlers run for a very short
> > > 
> > > you mean hard irq handlers "should run" for a very short time. There can
> > > be slow hardware that needs a long time, and fast hardware that needs a
> > > short time, and in turn it makes perfect sense to allow nesting to give
> > > low latency to the "fast" onces, like it has always happened so far (not
> > > only in linux AFIK). Disabling nesting completely sounds a very bad
> > > idea to me, when "limiting nesting" can be achieved easily as confirmed
> > > by Alan too.
> > 
> > IIRC, what we did in PTX was have 16 SPL levels, each interrupt was assigned
> > a prio, and higher prio interrupts could interrupt lower prio ones (but not
> > the same prio or higher). There's some support for that in the APIC, I think,
> > something like the high nybble is prio, and the low nybble is just an index.
> 
> Currently we do use priorities on i386/APIC, albeit unintentionally by 
> assigning higher IRQs higher vectors resulting in a higher priority.

Are these really "priorities" in real life?  I am not being facetious,
this is actually a common myth among users, that you will get better
performance by putting the device you care about on a "high priority"
irq or tweaking the priorities in your local APIC.  My impression was
that this is pointless because it only determines which interrupt the
CPU sees first if they fire at _exactly_ the same time.  Since we allow
interrupt to nest this does not matter in practice, right?

Lee