Date: Wed, 02 May 2007 09:22:33 -0700 From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@freebsd.org> Cc: cvs-src@freebsd.org, Darren Reed <darrenr@hub.freebsd.org>, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_intr.c src/sys/sys interrupt.h Message-ID: <4638BAC9.7000603@root.org> In-Reply-To: <200705021056.34887.jhb@freebsd.org> References: <200705020615.l426FDo7015874@repoman.freebsd.org> <20070502070707.GA68774@hub.freebsd.org> <200705021056.34887.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4638BAC9.7000603>