Date: Tue, 2 Aug 2005 11:16:13 -0400 (EDT) From: Rob Watt <rob@hudson-trading.com> To: freebsd-amd64@freebsd.org Cc: rob work <rob@hudson-trading.com> Subject: Re: fatal trap 12 in pagedaemon on dual-core opteron machine Message-ID: <20050726135103.V18252@daemon.mistermishap.net> In-Reply-To: <42D06471.6080105@mWare.ca> References: <20050630160225.D38285@daemon.mistermishap.net> <42D06471.6080105@mWare.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Gary, Thanks for the debug.mpsafenet reccomendation. It did solve our stability problem with our mulitcast application. I ran over 100 replays of the data that caused the panic, and we no longer panic when debug.mpsafenet=0. Unfortunately, our tcp applications now utilize a much higher percentage of cpu. We now regularly get a load of 3, and the interactive response of the machine is much worse. It takes up to 30 seconds to log in to the machine when our tcp applications are running, and the lag while working on the machine makes it feel like we're using a 1200 baud modem rather than gigabit ethernet. Our tcp apps function similarly to our multicast apps, they simultaneously listen to tcp data, record the data, and re-broadcast the data using multicast. The load while listening to the same data with debug.mpsafenet=1 is 0.2, and on an i386 fbsd 4.11 machine the load is comparable at 0.25, and there is no noticeable lag while working on the machine. At our average data load I was not able to measure a big drop off in tcp performance, but I am concerned by the increased cpu load and interactivity performance. We are not willing to use debug.mpsafenet=0 if this performance drop is the price to pay. After reading some of Robert Watson's notes on fine tuning the multi-threaded network stack it seems that many fixes are being applied to current, but not all of them are applied to stable. We are not willing to run CURRENT on our productions machines. Does anyone know if patches are planned for STABLE (either for increasing performance with GIANT on, or for making the multi-threaded network stack more stable)? Thanks - Rob Watt On Mon, 11 Jul 2005, Gary wrote: >All, > >I can confirm that I've had numerous crashes that seem to be network >related using 5.4R AMD64 on a dual AMD Tyan S2882 Thunder K8S PRO. > >Removing the Berkley Packet Filter and IPFilter from the kernel reduced >the frequency of the crashes. Moving from the onboard bge to the onboard >fxp interface didn't seem to make much difference. Running the GENERIC >uniprocessor kernel seemed to eliminate the problems. > >I got conformation that there seems to be locking issues with the multi >threaded implementation of the network stack from Gleb Smirnoff >(glebius at freebsd.org). Gleb suggested setting "debug.mpsafenet=0" to >turn off multi-threaded networking (as far as I understand): > >http://lists.freebsd.org/pipermail/freebsd-current/2004-August/035253.html > >This initially looked like it fixed the problem, but my system crashed >again a day later. > >Gary - Rob Watt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050726135103.V18252>