Re: Interrupt storm mitigation needed

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Thu, Feb 12, 2015 at 09:02:37PM -0500, Thor Lancelot Simon wrote:
> On Thu, Feb 12, 2015 at 07:52:10PM +0100, Tom Ivar Helbekkmo wrote:
> > Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost> writes:
> > 
> > > The uhci pins on the ioapics are chalking up a few interrupts, but not
> > > many, and no bursts.
> > 
> > Still nothing bad happening, but I did reboot just now, and saw
> > something that I've observered a few times lately: when the machine was
> > just sufficiently up that I could log in, 'vmstat -i' told me that the
> > ioapic pin for uhci2 had already generated slightly more than 210000
> > interrupts.
> 
> I guess the next question would then be whether, with uhci in polled mode,
> we can safely mask that pin.

From what I see from the original message, there are two issues:

(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. 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. I'm not much
in favour of doing the mitigation in the generic code as there are valid
situations for getting more than 10k interrupts per second on a device
-- older network cards without interrupt moderation for example. If that
is the correct load, it is not a bug.

Joerg