Date: Mon, 1 Nov 2004 17:03:17 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Shunsuke SHINOMIYA <shino@fornext.org> Cc: obrien@FreeBSD.org Subject: Re: disabling interrupt storm protection Message-ID: <200411011703.17866.jhb@FreeBSD.org> In-Reply-To: <20041030105024.360A.SHINO@fornext.org> References: <20041028165604.DCF8.SHINO@fornext.org> <200410281111.24398.jhb@FreeBSD.org> <20041030105024.360A.SHINO@fornext.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 29 October 2004 11:37 pm, Shunsuke SHINOMIYA wrote: > Thank you John, > > I wrote a patch(which is attached to this mail) so that the problem > doesn't occur in my environment. > > This patch changes the meaning of `storm'. > But, I think use of the parameter(hw_intr_threshold) to control the > detector in this method is clearer than the present method, and it > needs no DELAY(1). > > In the detector to which this patch is applied and compiled with > -DHACK2 flag, `storm' is the situation that the number of generated > interrupts per unit time(1/hz) is larger than threshold. > > If kern_intr.c is compiled with -DHACK2 -DHACK3 flags, it works as > interrupt rate limiter. > > What do you think about this method? A true interrupt storm that is trying to be handled here is not necessarily a high rate of interrupts (that can just be high load, but that is ok), but instead when a level triggered interrupt isn't handled it ends up firing again as soon as you re-enable interrupts. The goal is to at least give the system some time to run with the constantly interrupting source disabled so that other work can be done. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411011703.17866.jhb>