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_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.orgReceived on Mon Nov 01 2004 - 21:18:17 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:20 UTC