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

[Bill Davidsen <davidsen@tmr.com>]

Lee Revell wrote:
> On Fri, 2004-09-10 at 11:34, Arjan van de Ven wrote:
> 
>>On Fri, Sep 10, 2004 at 05:28:52PM +0200, Andrea Arcangeli wrote:
>>
>>>On Fri, Sep 10, 2004 at 05:15:38PM +0200, Arjan van de Ven wrote: 
>>>
>>>>What we should consider regardless is disable the nesting of irqs for
>>>>performance reasons but that's an independent matter
>>>
>>>disabling nesting completely sounds a bit too aggressive, but limiting
>>>the nesting is probably a good idea.
>>
>>disabling is actually not a bad idea; hard irq handlers run for a very short
>>time
> 
> 
> The glaring exception is the IDE io completion, which can run for 2000+
> usec even with a modern chipset and drive.  Here's a 600 usec trace:
> 
> http://krustophenia.net/testresults.php?dataset=2.6.8-rc4-bk3-O7#/var/www/2.6.8-rc4-bk3-O7/ide_irq_latency_trace.txt
> 
> The timer, RTC, and soundcard interrupts (among others) will not like
> being delayed this long.  Ingo mentioned that this was not always done
> in hardirq context; presumaby the I/O completion was done in a softirq
> like SCSI.  What was the motivation for moving such a long code path
> into the hard irq handler?

Certainly if you run ppp the serial port won't like being ignored that 
long, and if you pull down data on a parallel port that really won't 
like it. The soundcard is probably only a problem if you're recording 
input, in spite of some posts here about skipping, the world doesn't end 
if you get a skip, although 2ms shouldn't cause that anyway.

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979