From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 07:58:47 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D50D137B401; Fri, 15 Aug 2003 07:58:47 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5715943FB1; Fri, 15 Aug 2003 07:58:46 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h7FEwiv05943; Fri, 15 Aug 2003 16:58:44 +0200 (MEST) Date: Fri, 15 Aug 2003 16:58:44 +0200 (CEST) From: Harti Brandt To: Thomas Moestl In-Reply-To: <20030815135034.GA701@crow.dom2ip.de> Message-ID: <20030815165603.R92087@beagle.fokus.fraunhofer.de> References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jmg@freebsd.org cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 14:58:48 -0000 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