cvs commit: src/sys/kern kern_intr.c src/sys/sys interrupt.h

[Nate Lawson]

John Baldwin wrote:
> On Wednesday 02 May 2007 03:07:07 am Darren Reed wrote:
>> On Wed, May 02, 2007 at 06:15:13AM +0000, Nate Lawson wrote:
>>> njl         2007-05-02 06:15:13 UTC
>>>
>>>   FreeBSD src repository
>>>
>>>   Modified files:        (Branch: RELENG_6)
>>>     sys/kern             kern_intr.c 
>>>     sys/sys              interrupt.h 
>>>   Log:
>>>   MFC: rate-check the interrupt storm message and bump the counter 500 -> 
> 1000
>> Is this number, "500" or "1000" somehow "magical" for modern hardware?
>>
>> If I had a 500MHZ, 1GHz, 1.5GHz, 2GHz, 2.5GHz machines, each with the
>> appropriate architecture, what would the correct value for this be?
>> Is i always 1000 or should it be calculated?
> 
> It's a SWAG and tunable for machines where it doesn't work.  In practice the 
> old setting seemed to be a bit too trigger-happy as I know my printer always 
> triggered it, for example.
> 

There's more to it than just your Ghz number.  It's a counter of the
number of times an interrupt has triggered while the previous one was
being serviced.  The faster your kernel, the lower the number could be.

I have a slow early SMP Celeron system with a dc(4) adapter with 4 ports
sharing an irq with my ata.  At 3 am, the nightly script kicks off
enough IO that it triggers a bug in my dc(4) card that causes it to mask
the interrupt too long.  Then, the irq storm suppression logic kicked
in, causing ata to timeout the request.  The drive is on a mirror so I'd
lose half the mirror, then rebuild in the morning.  With this value
bumped, I don't have that problem any more but the real issue is why
dc(4) is being so quirky under heavy shared irq load.

-- 
Nate