From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 08:34:50 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 C88FB37B401 for ; Fri, 15 Aug 2003 08:34:50 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BD59943FDF for ; Fri, 15 Aug 2003 08:34:48 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 24796 invoked by uid 65534); 15 Aug 2003 15:34:47 -0000 Received: from p508E5396.dip.t-dialin.net (EHLO galatea.local) (80.142.83.150) by mail.gmx.net (mp012) with SMTP; 15 Aug 2003 17:34:47 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19ngbS-0000uM-9L; Fri, 15 Aug 2003 17:34:58 +0200 Date: Fri, 15 Aug 2003 17:34:58 +0200 From: Thomas Moestl To: harti@freebsd.org Message-ID: <20030815153458.GC701@crow.dom2ip.de> Mail-Followup-To: harti@freebsd.org, jmg@freebsd.org, sparc64@freebsd.org References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> <20030815165603.R92087@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030815165603.R92087@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl 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 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 15:34:51 -0000 On Fri, 2003/08/15 at 16:58:44 +0200, Harti Brandt wrote: > 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? Yes. > Wouldn't it help to make it the default? Otherwise the testing will be > rather limited. I haven't made it the default because it can require configuration changes because of the different enumeration, as detailed in the warning notice in GENERIC and NOTES. I had hoped that making it an option would allow people could gradually change over their installations, so that the transition would be more painless. I guess I should make it the default soon. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C