From owner-freebsd-arm@FreeBSD.ORG Sun Mar 7 07:00:17 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3F591065670 for ; Sun, 7 Mar 2010 07:00:16 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 63DAD8FC25 for ; Sun, 7 Mar 2010 07:00:16 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o2770E4C028464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 7 Mar 2010 08:00:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o2770BZY047307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Mar 2010 08:00:11 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o2770BBC009311; Sun, 7 Mar 2010 08:00:11 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o2770Akh009310; Sun, 7 Mar 2010 08:00:10 +0100 (CET) (envelope-from ticso) Date: Sun, 7 Mar 2010 08:00:10 +0100 From: Bernd Walter To: Maks Verver Message-ID: <20100307070010.GO58319@cicely7.cicely.de> References: <4B92BD9D.6030709@geocities.com> <20100306211715.GK58319@cicely7.cicely.de> <20100306215153.GL58319@cicely7.cicely.de> <20100306.152603.716362616846278503.imp@bsdimp.com> <4B9303E4.3090500@geocities.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B9303E4.3090500@geocities.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 07:00:17 -0000 On Sun, Mar 07, 2010 at 02:39:48AM +0100, Maks Verver wrote: > On 03/06/2010 10:17 PM, Bernd Walter wrote: > > Such massive speed difference sounds a bit like cache problems. > > On 03/06/2010 11:26 PM, M. Warner Losh wrote: > > Sounds a lot like ICACHE isn't being enabled, since a 3-liner like > > this should be executing entirely out of cache after the first > > instruction in main prefetches the cache line. > > Thanks for the quick responses! I think the both of you are right. I > didn't realize the cache could be turned off at all, but the boot output > shows: > > CPU: Feroceon 88FR131 rev 1 (write-through core) > WB enabled EABT branch prediction enabled > 16KB/32B 4-way Instruction cache > 16KB/32B 4-way write-back-locking-C Data cache > > This is different from the output on the wiki (which instructions I > followed, to some extent) at http://wiki.freebsd.org/FreeBSDMarvell: > > CPU: ARM926EJ-S rev 0 (ARM9EJ-S core) > DC enabled IC enabled WB enabled EABT branch prediction enabled > 32KB/32B 1-way Instruction cache > 32KB/32B 4-way write-back-locking-C Data cache > > Note that this guy is not running a SheevaPlug; the CPU is different. That's probably just because of different CPUs. I see a similar output on all of my systems with ARM920T CPU and still there is something wrong. I just verified with my 7.0-current system: [102]arm9# ./test 200.000u 3.000s 12:51.47 26.3% 45+1512k 0+0io 0pf+0w The system is productive and isn't completely idle, but the time is still smaller, so it is hard to say if there is a problem as well. Most interesting is a 8.0-current system I have: [4]beaver.cicely.de> ./test 196.000u 1.000s 3:43.03 88.8% 44+1452k 0+0io 0pf+0w Still much slower than calculated 80 seconds though, but also much faster than on my 9-current system. > But it's clear enough that on my system both processor caches are > disabled (even though they are correctly identified) and this is > understandably catastrophic for performance. It's good to have that > figured out at least. :-) Your loop isn't doing any data access, so it's just saying something about ICACHE not working. > The logical next question is: why aren't these caches enabled? How is > this supposed to work? Is the bootloader supposed to enable the cache, > or the kernel? If the kernel, why isn't it doing this? (If it's the > bootloader's task, then it's strange that the Linux kernel has no > trouble enabling the cache with the same bootloader). That's a good question. The kernel identifies them as being enabled on my CPU, but is it really true? IS there something which disables it later or this code is already wrong. But maybe it is not ICACHE itself and the memory pages are just declared uncacheable? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.