Date: Fri, 15 Aug 2003 16:58:44 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Thomas Moestl <t.moestl@tu-bs.de> Cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... Message-ID: <20030815165603.R92087@beagle.fokus.fraunhofer.de> In-Reply-To: <20030815135034.GA701@crow.dom2ip.de> References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 15 Aug 2003, Thomas Moestl wrote: TM>On Fri, 2003/08/15 at 12:20:39 +0200, Harti Brandt wrote: TM>> TM>> Hi all, TM>> TM>> it seems I have identified which commit causes the slow down on some TM>> sparcs. The kernel from just before that commit works just fine, the TM>> kernel from just after it is 3x slower on my Ultra-10 (as was also TM>> reported by others). I have no idea why that happens. The only difference TM>> in the time -l report is user and system time going up by a factor of TM>> three and the involuntary context switches doubling. TM> TM>It seems that deferred errors (and thus the data access errors TM>generated due to PCI bus timeouts from non-existant devices) will TM>disable the instruction and data cache by resetting the corresponding TM>enable bits in the LSU control register, and the current code fails to TM>reenable them (which also requires a cache flush). A simple workaround TM>for now is to avoid triggering these errors, so enabling OFW_NEWPCI TM>should help. I can confirm that it helps. I assume that OFW_NEWPCI is currently there to allow testing and one day to throw the switch and remove the old stuff? Wouldn't it help to make it the default? Otherwise the testing will be rather limited. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030815165603.R92087>