Re: Interrupt storm mitigation needed

[Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost>]

Joerg Sonnenberger <joerg%britannica.bec.de@localhost> writes:

> (1) It's a shared interrupt.
> (2) uhci is generated interrupts when it should not.
>
> It's unlikely that we can do anything about (1), so I was trying to see
> if we can do something about (2). Note that this is not true polled mode
> in the sense of what is used during startup or in ddb.

So, is it a big change to give the ?hci drivers a polled mode option?
Something like a kernel config file option or sysctl variables that let
you select it for systems that need it?  Even though I'm not seeing the
multi-second hangs with your experimental change, the time the machine
takes to respond to an ICMP ECHO increases more than tenfold when the
storms hit.  Also, ehci now takes the biggest hit, even though it has no
active devices connected.

I haven't tried enabling SMP yet.  I'm assuming that I'll still get into
the deadlock situations if I do, and they always end with disk
corruption, which is a hassle... :)

> The next step would be to do some basic accounting of interrupt rate
> and if it is too high, turn off interrupt mask bits in uhci and switch
> to the callout.  When it goes down again, re-enable normal interrupt
> mode.

That would still mean implementing a "proper" polled mode, right?
Because otherwise you wouldn't be able to mask off the interrupt?  Or am
I misunderstanding something?

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"