From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 03:20:46 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 3967E37B401; Fri, 15 Aug 2003 03:20:46 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id B40DB43F93; Fri, 15 Aug 2003 03:20:44 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h7FAKdv12612; Fri, 15 Aug 2003 12:20:39 +0200 (MEST) Date: Fri, 15 Aug 2003 12:20:39 +0200 (CEST) From: Harti Brandt To: sparc64@freebsd.org Message-ID: <20030815121010.I97608@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jmg@freebsd.org Subject: 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 10:20:46 -0000 Hi all, it seems I have identified which commit causes the slow down on some sparcs. The kernel from just before that commit works just fine, the kernel from just after it is 3x slower on my Ultra-10 (as was also reported by others). I have no idea why that happens. The only difference in the time -l report is user and system time going up by a factor of three and the involuntary context switches doubling. It is also not (easily) possible to revert that commit, because of other changes (for example, pci.c:1.220). When I simply revert the change, the machine gets a missed data trap when accessing register 14 on non-existing slots, when I add register 14 in the if() at the start of psycho_read_config, the machine freezes after finding pci1. Could please someone of the low-level sparc experts look at the problem? While doing my binary search I also noted a gradual shift in performace with time in the order of 5% (performance getting worse) in two month. Wouldn't it be feasable to, let's say, run once or twice a week two simple benchmarks (one disk bound, the other cpu bound) on a fresh kernel and have the results available on a web-site, so that we can note such performance shifts? Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org ---------- Forwarded message ---------- Date: Sat, 21 Jun 2003 18:26:08 -0700 (PDT) From: John-Mark Gurney To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/sparc64/include bus.h cpufunc.h src/sys/sparc64/pci psycho.c src/sys/sparc64/sparc64 support.S trap.c jmg 2003/06/21 18:26:08 PDT FreeBSD src repository Modified files: sys/sparc64/include bus.h cpufunc.h sys/sparc64/pci psycho.c sys/sparc64/sparc64 support.S trap.c Log: add support for peeking at pci busses on UltraSparc systems. This prevents data access errors when trying to read/write to non-existant PCI devices. fix the psycho bridge to use peek for probing devices. This no longer fakes it if the OFW node doesn't exist (and the reg == 0). Reviewed by: jake, tmm Revision Changes Path 1.28 +27 -0 src/sys/sparc64/include/bus.h 1.17 +9 -0 src/sys/sparc64/include/cpufunc.h 1.39 +19 -12 src/sys/sparc64/pci/psycho.c 1.27 +52 -0 src/sys/sparc64/sparc64/support.S 1.64 +25 -0 src/sys/sparc64/sparc64/trap.c