From owner-freebsd-arm@FreeBSD.ORG Sun Oct 18 11:36:28 2009 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 362DD106566B; Sun, 18 Oct 2009 11:36:28 +0000 (UTC) (envelope-from gballet@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 94BFF8FC0C; Sun, 18 Oct 2009 11:36:27 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so770249eyd.9 for ; Sun, 18 Oct 2009 04:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Khu0evFpU9BqGjgIBP5d/yYWIm8dB3eAJ1owxvLXEEM=; b=BeMMVQQdJnHwCQV8Svqnykd7uLllTGcTkV0EDlB2YxmHHt1WpYbueIz9KBeuLeuo7R F8KymHPjtMK8C2WvWsTtstJSFrRI8OhzFZNttUMST/fK/+daLOR5XQjO6requ81727PU 3RtN9W5z6bm6nplgjdBg1A/I+NAyt9OLOegX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eiyztnzvlCaGwpUFIfY4Uectn688317Isw3UPxjwif9PqM7T8Dmmmvqm2eWIQyDdSK wY/7qlHBUP9Emz13CcMOahiuVYhmPuSYm98kDvUyTkxh+XgYX+0hLXIKJ+gJdEToI6U1 ixWv3PfoTveAUCAKemI0OciLDMeh8Iy0YVS1E= MIME-Version: 1.0 Received: by 10.211.174.10 with SMTP id b10mr4267576ebp.39.1255865785997; Sun, 18 Oct 2009 04:36:25 -0700 (PDT) In-Reply-To: <200910122129.n9CLTHsp087996@casselton.net> References: <200910122129.n9CLTHsp087996@casselton.net> Date: Sun, 18 Oct 2009 13:36:25 +0200 Message-ID: From: Guillaume Ballet To: Mark Tinguely Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org, stas@deglitch.com Subject: Re: Adding members to struct cpu_functions X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 11:36:28 -0000 On Mon, Oct 12, 2009 at 11:29 PM, Mark Tinguely wr= ote: > >> =A0As a result, extending the struct cpu_functions is not a good thing >> =A0either, for the same reason. The compiler can not inline a call >> =A0through a function pointer. >> >> =A0In which case, why not create a bunch of headers files with the >> =A0pattern cpufunc_myarch.h, in which all functions would be declared >> =A0inline? Something like: >> >> =A0static inline l2_l_entry(vm_addr_t pa, int prot, int cache); >> =A0static inline l2_s_entry(vm_addr_t pa, int prot, int cache); >> =A0... >> =A0which would then be included by pmap.c and friends. > > I think they need to be regular function calls because assembly routines > call the per-cpu functions. A few simple macros would save the branch to = NOP > functions. > I'm not sure what you mean by that: would macros be ok, in your opinion? I am a bit puzzled because I see a contradiction with the previous sentence that requires the functions to be callable from the assembly code. Obviously I am misinterpreting, so would you mind clarifying, please? I think it is important to notice that even though cache management relies a lot on assembly function, I haven't found any page table management done in assembly past locore.S. I think using macros for page table management functions can be done. For cache management, however, I agree that having different pmap.c files is probably the way to go. In both cases, I am still curious to see what Nathan will come up with. I took a more thorough look at pmap, and there is indeed lots of machine-specific code, especially at the beginning. And when it comes to cpufunc, it's all about #ifdefs. Since I'm still working on the cleanup for the beagleboard, I will declare cpufuncs in an armv6-specific file. Let's call it cpufunc_armv6.c. I am struggling with another MMU problem at the moment, but I'll try to come up asap with a patch for pmap.c. It will replace hardcoded values with machine-defined macros, for reference. Guillaume From owner-freebsd-arm@FreeBSD.ORG Sun Oct 18 14:05:50 2009 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 4D0411065679; Sun, 18 Oct 2009 14:05:50 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 03C568FC2A; Sun, 18 Oct 2009 14:05:49 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n9IE5hGU093572; Sun, 18 Oct 2009 09:05:43 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1255874743; bh=NfjGg/wUXkieaPNy6sTOprE+yD+Z91E+iOmjj9YivjM=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=Ajb6Qg3wO6IkFNHus7Ers+m5x2djVFqfDIsgOqKtZ4TRZylwESY1xajb0BZXyJ3/C FJ/tqXzxjABCBH7zESQL11PyAxREpFE/wAbDQzelFyN+EBDXdVVt0n/mbvz3yL4bqn 0MxZGI0c5XSV6G3JZonz3/tRZEOYwCv2P53+CtuA= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n9IE5gsi093570; Sun, 18 Oct 2009 09:05:42 -0500 (CDT) (envelope-from tinguely) Date: Sun, 18 Oct 2009 09:05:42 -0500 (CDT) From: Mark Tinguely Message-Id: <200910181405.n9IE5gsi093570@casselton.net> To: gballet@gmail.com, tinguely@casselton.net In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Sun, 18 Oct 2009 09:05:43 -0500 (CDT) Cc: freebsd-arm@freebsd.org, stas@deglitch.com Subject: Re: Adding members to struct cpu_functions X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 14:05:50 -0000 > >> =A0either, for the same reason. The compiler can not inline a call > >> =A0through a function pointer. > >> > >> =A0In which case, why not create a bunch of headers files with the > >> =A0pattern cpufunc_myarch.h, in which all functions would be declared > >> =A0inline? Something like: > >> > >> =A0static inline l2_l_entry(vm_addr_t pa, int prot, int cache); > >> =A0static inline l2_s_entry(vm_addr_t pa, int prot, int cache); > >> =A0... > >> =A0which would then be included by pmap.c and friends. > > > > I think they need to be regular function calls because assembly routines > > call the per-cpu functions. A few simple macros would save the branch to = > NOP > > functions. > > > > I'm not sure what you mean by that: would macros be ok, in your > opinion? I am a bit puzzled because I see a contradiction with the > previous sentence that requires the functions to be callable from the > assembly code. Obviously I am misinterpreting, so would you mind > clarifying, please? > > I think it is important to notice that even though cache management > relies a lot on assembly function, I haven't found any page table > management done in assembly past locore.S. I think using macros for > page table management functions can be done. For cache management, > however, I agree that having different pmap.c files is probably the > way to go. In both cases, I am still curious to see what Nathan will > come up with. You are correct, the page tables routines are pmap.c oriented. I extended clean up thought to all the cpu specific functions. There are cpu specific functions that are NOPs that we branch to and back again. I was just throwing out a global re-organization thought. > I took a more thorough look at pmap, and there is indeed lots of > machine-specific code, especially at the beginning. And when it comes > to cpufunc, it's all about #ifdefs. Since I'm still working on the > cleanup for the beagleboard, I will declare cpufuncs in an > armv6-specific file. Let's call it cpufunc_armv6.c. I am struggling > with another MMU problem at the moment, but I'll try to come up asap > with a patch for pmap.c. It will replace hardcoded values with > machine-defined macros, for reference. I think you are running that processor in v5 mode. There is still some individuals looking at a cache problem with recent code. I still believe, we need to add the PVF_REF flag when adding the new unmanaged (PVF_UNMAN) pv_entry, so pmap_fix_cache() will clean write back the cache and remove the tlb. That and the changes to remove dangling allocations. --Mark. From owner-freebsd-arm@FreeBSD.ORG Sun Oct 18 15:49:19 2009 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 7BB701065672 for ; Sun, 18 Oct 2009 15:49:19 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 4BE078FC13 for ; Sun, 18 Oct 2009 15:49:18 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7.0-5.01 32bit (built Feb 19 2009)) id <0KRP00702VY5BG00@smtpauth3.wiscmail.wisc.edu> for freebsd-arm@freebsd.org; Sun, 18 Oct 2009 10:49:17 -0500 (CDT) Received: from comporellon.tachypleus.net (adsl-75-50-88-75.dsl.mdsnwi.sbcglobal.net [75.50.88.75]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7.0-5.01 32bit (built Feb 19 2009)) with ESMTPSA id <0KRP004ILVY3BO20@smtpauth3.wiscmail.wisc.edu>; Sun, 18 Oct 2009 10:49:16 -0500 (CDT) Date: Sun, 18 Oct 2009 10:49:14 -0500 From: Nathan Whitehorn In-reply-to: <4AD39C78.5050309@freebsd.org> To: Rafal Jaworowski Message-id: <4ADB38FA.2080604@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=75.50.88.75 X-Spam-PmxInfo: Server=avs-14, Version=5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2009.10.18.153320, SenderIP=75.50.88.75 References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <4AD32D76.3090401@freebsd.org> <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> <4AD39C78.5050309@freebsd.org> User-Agent: Thunderbird 2.0.0.23 (X11/20090905) Cc: Guillaume Ballet , Mark Tinguely , freebsd-arm@freebsd.org, Stanislav Sedov Subject: Re: Adding members to struct cpu_functions X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 15:49:19 -0000 Nathan Whitehorn wrote: > Rafal Jaworowski wrote: >> >> On 2009-10-12, at 15:21, Nathan Whitehorn wrote: >> >>>>>> I was wondering whether a separate pmap module for ARMv6-7 would not >>>>>> be the best approach. After all v6-7 should be considered an >>>>>> entirely >>>>>> new architecture variation, and we would avoid the very likely >>>>>> #ifdefs >>>>>> hell in case of a single pmap.c. >>>>>> >>>>>> >>>>> Yeah, I think that would be the best solution. We could >>>>> conditionally >>>>> select the right pmap.c file based on the target CPU selected (just >>>>> like we do for board variations for at91/marvell). >>>>> >>>>> >>>> >>>> pmap.c is a very large file that seems to change very often. I fear >>>> having several versions is going to be difficult to maintain. Granted, >>>> I haven't read the whole file line after line. Yet it seems to me its >>>> content can be abstracted to rely on arch-specific functions that >>>> would be found in cpufuncs instead of hardcoded macros. Is there >>>> something fundamentally wrong with enhancing struct cpufunc in order >>>> to let the portmeisters decide what the MMU and caching bits should >>>> look like? This is a blocking issue for me, since it looks like the >>>> omap has some problem with backward compatibility mode. Without fixing >>>> up the TLBs in my initarm function, it doesn't work. >>>> >>>> Speaking of #ifdef hell, why not breaking cpufuncs.c into several >>>> cpufuncs_.c? That would be a good way to start that >>>> reorganization Mark has been talking about in his email. >>>> >>> One thing that might be worth looking at while thinking about this >>> is how this is done on PowerPC. We have run-time selectable PMAP >>> modules using KOBJ to handle CPUs with different MMU designs, as >>> well as a platform module scheme, again using KOBJ, to pick the >>> appropriate PMAP for the board as well as determine the physical >>> memory layout and such things. One of the nice things about the >>> approach is that it is easy to subclass if you have a new, >>> marginally different, design, and it avoids #ifdef hell as well as >>> letting you build a GENERIC kernel with support for multiple MMU >>> designs and board types (the last less of a concern on ARM, though). >> >> What always concerned me was the performance cost this imposes, and >> it would be a really useful exercise to measure what is the actual >> impact of KOBJ-tized pmap we have in PowerPC; with an often-called >> interface like pmap it might occur the penalty is not that little.. > Using the KOBJ cache means that it is only marginally more expensive > than a standard function pointer call. There's a 9-year-old note in > the commit log for sys/sys/kobj.h that it takes about 30% longer to > call a function that does nothing via KOBJ versus a direct call on a > 300 MHz P2 (a 10 ns time difference). Given that and that pmap methods > do, in fact, do things besides get called and immediately return, I > suspect non-KOBJ related execution time will dwarf any time loss from > the indirection. I'll try to repeat the measurement in the next few > days, however, since this is important to know. > -Nathan I just did the measurements on a 1.8 GHz PowerPC G5. There were four tests, each repeated 1 million times. "Load and store" involves incrementing a volatile int from 0 to 1e6 inline. "Direct calls" involves a branch to a function that returns 0 and does nothing else. "Function ptr" calls the same function via a pointer stored in a register, and "KOBJ calls" calls it via KOBJ. Here are the results (errors are +/- 0.5 ns for the function call measurements due to compiler optimization jitter, and 0 for load and store, since that takes a deterministic number of clock cycles): 32-bit kernel: Load and store: 26.1 ns Direct calls: 7.2 ns Function ptr: 8.4 ns KOBJ calls: 17.8 ns 64-bit kernel: Load and store: 9.2 ns Direct calls: 6.1 ns Function ptr: 8.3 ns KOBJ calls: 40.5 ns ABI changes make a large difference, as you can see. The cost of calling via KOBJ is non-negligible, but small, especially compared to the cost of doing anything involving memory. I don't know how this changes with ARM calling conventions. -Nathan From owner-freebsd-arm@FreeBSD.ORG Mon Oct 19 11:06:49 2009 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 85D201065672 for ; Mon, 19 Oct 2009 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7461B8FC19 for ; Mon, 19 Oct 2009 11:06:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9JB6n3B063383 for ; Mon, 19 Oct 2009 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9JB6mkl063381 for freebsd-arm@FreeBSD.org; Mon, 19 Oct 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Oct 2009 11:06:48 GMT Message-Id: <200910191106.n9JB6mkl063381@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 11:06:49 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Oct 19 15:34:03 2009 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 2D5D11065670; Mon, 19 Oct 2009 15:34:03 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 941438FC0C; Mon, 19 Oct 2009 15:34:02 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 16EE3C3BA8; Mon, 19 Oct 2009 17:28:34 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id kfyITc-hCZhX; Mon, 19 Oct 2009 17:28:32 +0200 (CEST) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id D924FC3B9C; Mon, 19 Oct 2009 17:28:32 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Rafal Jaworowski In-Reply-To: <4ADB38FA.2080604@freebsd.org> Date: Mon, 19 Oct 2009 17:33:59 +0200 Content-Transfer-Encoding: 7bit Message-Id: <05B19969-B238-4E3A-8326-624067F0362B@semihalf.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <4AD32D76.3090401@freebsd.org> <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> <4AD39C78.5050309@freebsd.org> <4ADB38FA.2080604@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1076) Cc: Guillaume Ballet , Mark Tinguely , freebsd-arm@freebsd.org, Stanislav Sedov Subject: Re: Adding members to struct cpu_functions X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 15:34:03 -0000 On 2009-10-18, at 17:49, Nathan Whitehorn wrote: >>>> One thing that might be worth looking at while thinking about >>>> this is how this is done on PowerPC. We have run-time selectable >>>> PMAP modules using KOBJ to handle CPUs with different MMU >>>> designs, as well as a platform module scheme, again using KOBJ, >>>> to pick the appropriate PMAP for the board as well as determine >>>> the physical memory layout and such things. One of the nice >>>> things about the approach is that it is easy to subclass if you >>>> have a new, marginally different, design, and it avoids #ifdef >>>> hell as well as letting you build a GENERIC kernel with support >>>> for multiple MMU designs and board types (the last less of a >>>> concern on ARM, though). >>> >>> What always concerned me was the performance cost this imposes, >>> and it would be a really useful exercise to measure what is the >>> actual impact of KOBJ-tized pmap we have in PowerPC; with an often- >>> called interface like pmap it might occur the penalty is not that >>> little.. >> Using the KOBJ cache means that it is only marginally more >> expensive than a standard function pointer call. There's a 9-year- >> old note in the commit log for sys/sys/kobj.h that it takes about >> 30% longer to call a function that does nothing via KOBJ versus a >> direct call on a 300 MHz P2 (a 10 ns time difference). Given that >> and that pmap methods do, in fact, do things besides get called and >> immediately return, I suspect non-KOBJ related execution time will >> dwarf any time loss from the indirection. I'll try to repeat the >> measurement in the next few days, however, since this is important >> to know. >> -Nathan > I just did the measurements on a 1.8 GHz PowerPC G5. There were four > tests, each repeated 1 million times. "Load and store" involves > incrementing a volatile int from 0 to 1e6 inline. "Direct calls" > involves a branch to a function that returns 0 and does nothing > else. "Function ptr" calls the same function via a pointer stored in > a register, and "KOBJ calls" calls it via KOBJ. Here are the results > (errors are +/- 0.5 ns for the function call measurements due to > compiler optimization jitter, and 0 for load and store, since that > takes a deterministic number of clock cycles): > > 32-bit kernel: > Load and store: 26.1 ns > Direct calls: 7.2 ns > Function ptr: 8.4 ns > KOBJ calls: 17.8 ns > > 64-bit kernel: > Load and store: 9.2 ns > Direct calls: 6.1 ns > Function ptr: 8.3 ns > KOBJ calls: 40.5 ns > > ABI changes make a large difference, as you can see. The cost of > calling via KOBJ is non-negligible, but small, especially compared > to the cost of doing anything involving memory. I don't know how > this changes with ARM calling conventions. Very interesting, thanks! Could you elaborate on the testing details and share the diagnostic code so we could repeat this with other CPU variations like Book-E PowerPC, or ARM? Rafal From owner-freebsd-arm@FreeBSD.ORG Mon Oct 19 15:54:12 2009 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 EE9DF106566C; Mon, 19 Oct 2009 15:54:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A8ADE8FC21; Mon, 19 Oct 2009 15:54:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n9JFlrHx089298; Mon, 19 Oct 2009 09:47:53 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 19 Oct 2009 09:47:58 -0600 (MDT) Message-Id: <20091019.094758.-2092524312.imp@bsdimp.com> To: raj@semihalf.com From: "M. Warner Losh" In-Reply-To: <05B19969-B238-4E3A-8326-624067F0362B@semihalf.com> References: <4AD39C78.5050309@freebsd.org> <4ADB38FA.2080604@freebsd.org> <05B19969-B238-4E3A-8326-624067F0362B@semihalf.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: gballet@gmail.com, tinguely@casselton.net, freebsd-arm@freebsd.org, stas@deglitch.com Subject: Re: Adding members to struct cpu_functions X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 15:54:13 -0000 In message: <05B19969-B238-4E3A-8326-624067F0362B@semihalf.com> Rafal Jaworowski writes: : On 2009-10-18, at 17:49, Nathan Whitehorn wrote: [[ trimmed ]] : > I just did the measurements on a 1.8 GHz PowerPC G5. There were four : > tests, each repeated 1 million times. "Load and store" involves : > incrementing a volatile int from 0 to 1e6 inline. "Direct calls" : > involves a branch to a function that returns 0 and does nothing : > else. "Function ptr" calls the same function via a pointer stored in : > a register, and "KOBJ calls" calls it via KOBJ. Here are the results : > (errors are +/- 0.5 ns for the function call measurements due to : > compiler optimization jitter, and 0 for load and store, since that : > takes a deterministic number of clock cycles): : > : > 32-bit kernel: : > Load and store: 26.1 ns : > Direct calls: 7.2 ns : > Function ptr: 8.4 ns : > KOBJ calls: 17.8 ns : > : > 64-bit kernel: : > Load and store: 9.2 ns : > Direct calls: 6.1 ns : > Function ptr: 8.3 ns : > KOBJ calls: 40.5 ns : > : > ABI changes make a large difference, as you can see. The cost of : > calling via KOBJ is non-negligible, but small, especially compared : > to the cost of doing anything involving memory. I don't know how : > this changes with ARM calling conventions. : : Very interesting, thanks! Could you elaborate on the testing details : and share the diagnostic code so we could repeat this with other CPU : variations like Book-E PowerPC, or ARM? I'd love to see this on MIPS too... KOBJ is a big win for device configuration, where one memory I/O can take 60 times these call numbers... Warner From owner-freebsd-arm@FreeBSD.ORG Mon Oct 19 20:35:45 2009 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 3C9E5106568D for ; Mon, 19 Oct 2009 20:35:45 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 11C9B8FC19 for ; Mon, 19 Oct 2009 20:35:44 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1MzyeL-0004OA-Fw for freebsd-arm@freebsd.org; Mon, 19 Oct 2009 13:16:13 -0700 Message-ID: <25964915.post@talk.nabble.com> Date: Mon, 19 Oct 2009 13:16:13 -0700 (PDT) From: RuiDC To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: ruidc@yahoo.com Subject: Sheevaplug: booting from tftp/nfs has root as read-only X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 20:35:45 -0000 Hi, I am using a Sheevaplug and 8.0-RC1 and I've followed the instructions here: http://wiki.freebsd.org/FreeBSDMarvell /etc/exports on my FreeBSD server is set up as follows: /usr/nfsroot/arm-8-le -mapall=0 -alldirs -network 0.0.0.0 -mask 0.0.0.0 If i access the NFS share from an ubuntu client, it's read/write but following the above instructions from the sheevaplug, although it boots fine otherwise, the root is mounted read-only. Any suggestions as to how i can debug and fix this? RuiDC -- View this message in context: http://www.nabble.com/Sheevaplug%3A-booting-from-tftp-nfs-has-root-as-read-only-tp25964915p25964915.html Sent from the freebsd-arm mailing list archive at Nabble.com. From owner-freebsd-arm@FreeBSD.ORG Tue Oct 20 09:15:32 2009 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 B4841106568F for ; Tue, 20 Oct 2009 09:15:32 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 6876E8FC1B for ; Tue, 20 Oct 2009 09:15:32 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 92ABDC3BA2; Tue, 20 Oct 2009 11:10:05 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id fMXt-C5Jmmp2; Tue, 20 Oct 2009 11:10:04 +0200 (CEST) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id CCDF1C3B9C; Tue, 20 Oct 2009 11:10:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Rafal Jaworowski In-Reply-To: <25964915.post@talk.nabble.com> Date: Tue, 20 Oct 2009 11:15:30 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2A3CAAF1-FD37-4F3B-B670-FD8BC38D8CF4@semihalf.com> References: <25964915.post@talk.nabble.com> To: RuiDC X-Mailer: Apple Mail (2.1076) Cc: freebsd-arm@freebsd.org Subject: Re: Sheevaplug: booting from tftp/nfs has root as read-only X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 09:15:32 -0000 On 2009-10-19, at 22:16, RuiDC wrote: > I am using a Sheevaplug and 8.0-RC1 and I've followed the > instructions here: > http://wiki.freebsd.org/FreeBSDMarvell > > /etc/exports on my FreeBSD server is set up as follows: > /usr/nfsroot/arm-8-le -mapall=0 -alldirs -network 0.0.0.0 -mask > 0.0.0.0 > > If i access the NFS share from an ubuntu client, it's read/write but > following the above instructions from the sheevaplug, although it > boots fine > otherwise, the root is mounted read-only. > > Any suggestions as to how i can debug and fix this? Are you running in multiuser? Does your /etc/fstab allow for RW? Rafal From owner-freebsd-arm@FreeBSD.ORG Tue Oct 20 12:51:34 2009 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 160D51065672 for ; Tue, 20 Oct 2009 12:51:34 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id DC6AA8FC0C for ; Tue, 20 Oct 2009 12:51:33 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1N0EBZ-00006L-5Z for freebsd-arm@freebsd.org; Tue, 20 Oct 2009 05:51:33 -0700 Message-ID: <25974519.post@talk.nabble.com> Date: Tue, 20 Oct 2009 05:51:33 -0700 (PDT) From: RuiDC To: freebsd-arm@freebsd.org In-Reply-To: <2A3CAAF1-FD37-4F3B-B670-FD8BC38D8CF4@semihalf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: ruidc@yahoo.com References: <25964915.post@talk.nabble.com> <2A3CAAF1-FD37-4F3B-B670-FD8BC38D8CF4@semihalf.com> Subject: Re: Sheevaplug: booting from tftp/nfs has root as read-only X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 12:51:34 -0000 Solved, thanks to Rafal: Rafal Jaworowski wrote: > > > Are you running in multiuser? > > Does your /etc/fstab allow for RW? > > /etc/fstab was fine: 192.168.2.233:/usr/nfsroot/arm-8-le / nfs rw 0 0 but i was running single-user. After using ^D after reading init(8) it came up read-write. Thanks, R -- View this message in context: http://www.nabble.com/Sheevaplug%3A-booting-from-tftp-nfs-has-root-as-read-only-tp25964915p25974519.html Sent from the freebsd-arm mailing list archive at Nabble.com. From owner-freebsd-arm@FreeBSD.ORG Tue Oct 20 15:12:55 2009 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 7BE2E106566B for ; Tue, 20 Oct 2009 15:12:55 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 5071E8FC12 for ; Tue, 20 Oct 2009 15:12:55 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1N0GOM-0001ZV-JE for freebsd-arm@freebsd.org; Tue, 20 Oct 2009 08:12:54 -0700 Message-ID: <25976957.post@talk.nabble.com> Date: Tue, 20 Oct 2009 08:12:54 -0700 (PDT) From: RuiDC To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: ruidc@yahoo.com Subject: Sheevaplug: preparing to boot from USB stick X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 15:12:55 -0000 I have followed http://wiki.freebsd.org/FreeBSDMarvell and am booting fine via tftp/NFS but now wish to switch to using USB stick so that the plug operates without a server. In the absence of a guide as to how to proceed, i was following from step 7 onwards from: http://bsdimp.blogspot.com/2007/12/building-bootable-arm-sd.html step7: # fdisk -I da0 ******* Working on device da0 ******* fdisk: /boot/mbr: No such file or directory Should i be using on of these instead: # ls -l boot ... -r--r--r-- 1 root wheel 13320 Sep 28 09:57 loader.help -r-xr-xr-x 1 root wheel 165864 Sep 28 09:57 ubldr And if so, what preparation do i need for the USB stick? ie. swapping is disabled on the kernel config, can i just use a single large UFS partition/slice ? as below or do i need a FAT32 partition to make it accessible from u-boot? # fdisk da0 ******* Working on device /dev/da0 ******* parameters extracted from in-core disklabel are: cylinders=972 heads=255 sectors/track=63 (16065 blks/cyl) parameters to be used for BIOS calculations are: cylinders=972 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 62, size 15620218 (7627 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 63; end: cyl 972/ head 80/ sector 60 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Thanks, RuiDC -- View this message in context: http://www.nabble.com/Sheevaplug%3A-preparing-to-boot-from-USB-stick-tp25976957p25976957.html Sent from the freebsd-arm mailing list archive at Nabble.com. From owner-freebsd-arm@FreeBSD.ORG Tue Oct 20 15:28:01 2009 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 7BAC91065672 for ; Tue, 20 Oct 2009 15:28:01 +0000 (UTC) (envelope-from jack.avenger@gmail.com) Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA158FC08 for ; Tue, 20 Oct 2009 15:28:00 +0000 (UTC) Received: by vws27 with SMTP id 27so2415732vws.3 for ; Tue, 20 Oct 2009 08:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=oFLQ4FxbbXlqiBzv4f8Gx1Cbiv6RqDfA/Lo/KsQwFgg=; b=sV2DlfK+NviDUPkkbd/59/bCmrZhmrHobxU3pfRx9n4XRbieizf6bFxXz6WwD6tyRx 31Ypeu4/e9v5h/jrAHPAHLF0+pLTqufLB1EHfaCM6/OuwvvE1cV6nqmmXDvVV8/rA0GX IQ6A7ZK3tyWo2dmOnN02bniUxe76NtK1ABois= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=QN8gTkXrT8BMFahlOewNS1U+C/x8ZJHj2KYhogDkr0uSw35pNyPZcZtslABXwTFB+Z 1LXcx387W4kOHacw2IDjrJWOLw0wCQsMiZdpRxO3gd6wTOZUZS0Y9qpWgFHisEKeDXBA Iqlvsf4TS163mJf8Fl8vnII2uDkX6H1oeztWA= Received: by 10.103.84.6 with SMTP id m6mr2745372mul.26.1256052479485; Tue, 20 Oct 2009 08:27:59 -0700 (PDT) Received: from ?10.2.3.41? (mail.nikel.com.ua [193.93.186.21]) by mx.google.com with ESMTPS id y37sm588971mug.4.2009.10.20.08.27.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Oct 2009 08:27:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) From: Jack Avenger In-Reply-To: <33436772.1965231256048531425.JavaMail.nabble@isper.nabble.com> Date: Tue, 20 Oct 2009 18:27:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <62E4AC76-198B-4C74-8318-E3399B4B35C7@gmail.com> References: <33436772.1965231256048531425.JavaMail.nabble@isper.nabble.com> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1076) Subject: Re: Can't boot Marvel Sheevaplug from USB X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 15:28:01 -0000 No. It doesn't work. See link: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D138798 On 20 =D0=B6=D0=BE=D0=B2=D1=82. 2009, at 17:22, ruidc@yahoo.com wrote: > Hi, did you eventually get this to work? > If so, how? > > RuiDC > > Jack Avenger wrote: >> >> Which options should be included in kernel configuration to boot 8- >> CURRENT on SHEEVAPLUG? >> >> I tried options ROOTDEVNAME=3D"ufs:/dev/da0s1a", but no success: >> >> usbus0: 480Mbps High Speed USB v2.0 >> Root mount waiting for: usbus0 >> ugen0.1: at usbus0 >> uhub0: on >> usbus0 >> uhub0: 1 port with 1 removable, self powered >> Root mount waiting for: usbus0 >> ugen0.2: at usbus0 >> umass0: on >> usbus0 >> umass0: SCSI over Bulk-Only; quirks =3D 0x0000 >> Root mount waiting for: usbus0 >> umass0:0:0:-1: Attached to scbus0 >> Trying to mount root from ufs:/dev/da0a >> ROOT MOUNT ERROR: >> If you have invalid mount options, reboot, and first try the =20 >> following >> from >> the loader prompt: >> >> set vfs.root.mountfrom.options=3Drw >> >> and then remove invalid mount options from /etc/fstab. >> >> Loader variables: >> vfs.root.mountfrom=3D >> vfs.root.mountfrom.options=3D >> >> Manual root filesystem specification: >> : Mount using filesystem >> eg. ufs:/dev/da0s1a >> eg. cd9660:/dev/acd0 >> This is equivalent to: mount -t cd9660 /dev/ >> acd0 / >> >> ? List valid disk boot devices >> Abort manual input >> >> mountroot> >> >> it seems like there is an error accessing USB Flash, but it work when >> boot from NFS is compiled into kernel. >> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-=20 >> unsubscribe@freebsd.org" >> >> > Quoted from: > = http://www.nabble.com/Can%27t-boot-Marvel-Sheevaplug-from-USB-tp25368842p2= 5368842.html > Yurij Burak jack.avenger@gmail.com From owner-freebsd-arm@FreeBSD.ORG Fri Oct 23 13:31:02 2009 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 637EE106566C for ; Fri, 23 Oct 2009 13:31:02 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id E2AEF8FC12 for ; Fri, 23 Oct 2009 13:31:01 +0000 (UTC) Received: by bwz5 with SMTP id 5so911591bwz.3 for ; Fri, 23 Oct 2009 06:30:58 -0700 (PDT) Received: by 10.204.3.19 with SMTP id 19mr10829602bkl.151.1256302711425; Fri, 23 Oct 2009 05:58:31 -0700 (PDT) Received: from terran.mk.farlep.net (i168-101-19-89.vpdn.way.kv.chereda.net [89.19.101.168]) by mx.google.com with ESMTPS id g28sm2956586fkg.45.2009.10.23.05.58.28 (version=SSLv3 cipher=RC4-MD5); Fri, 23 Oct 2009 05:58:29 -0700 (PDT) Sender: Alex RAY Date: Fri, 23 Oct 2009 15:58:25 +0300 From: Alexandr Rybalko To: Mark Tinguely , freebsd-arm@freebsd.org Message-Id: <20091023155825.381728f4.ray@dlink.ua> In-Reply-To: <200910071636.n97GaF11095976@casselton.net> References: <20091007114612.00408f53.ray@dlink.ua> <200910071636.n97GaF11095976@casselton.net> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: [ARM+NFS] panic while copying across NFS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 13:31:02 -0000 Hi Mark! With your patch works fine. # dd if=/swap.file of=/mnt/swap.file bs=1M 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 231.294150 secs (4642322 bytes/sec) But still slow. Maybe someone know why slow? (Marvell 88F5182 rev A2) On Wed, 7 Oct 2009 11:36:15 -0500 (CDT) Mark Tinguely wrote: >> >> (CC -arm and -current removed) >> >> Have you tried to remove the dangling allocations? I can't say that this >> will change anything, I would just feel better to eliminate them. >> >> ---- >> >> Revisions 181296 and 195779 added the cache fixes. >> >> Below are a couple more. We should remove the dangling allocations so >> they do not un-necessarily turn off the cache in the future. >> >> ---- >> >> Index: arm/arm/vm_machdep.c >> =================================================================== >> --- arm/arm/vm_machdep.c (revision 196359) >> +++ arm/arm/vm_machdep.c (working copy) >> @@ -172,6 +172,9 @@ sf_buf_free(struct sf_buf *sf) >> if (sf->ref_count == 0) { >> TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); >> nsfbufsused--; >> + pmap_kremove(sf->kva); >> + sf->m = NULL; >> + LIST_REMOVE(sf, list_entry); >> if (sf_buf_alloc_want > 0) >> wakeup_one(&sf_buf_freelist); >> } >> @@ -452,9 +455,12 @@ arm_unmap_nocache(void *addr, vm_size_t size) >> >> size = round_page(size); >> i = (raddr - arm_nocache_startaddr) / (PAGE_SIZE); >> - for (; size > 0; size -= PAGE_SIZE, i++) >> + for (; size > 0; size -= PAGE_SIZE, i++) { >> arm_nocache_allocated[i / BITS_PER_INT] &= ~(1 << (i % >> BITS_PER_INT)); >> + pmap_kremove(raddr); >> + raddr += PAGE_SIZE; >> + } >> } >> >> #ifdef ARM_USE_SMALL_ALLOC -- Alexandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Fri Oct 23 15:22:54 2009 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 5EE9A1065670 for ; Fri, 23 Oct 2009 15:22:54 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2C7988FC19 for ; Fri, 23 Oct 2009 15:22:54 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n9NFMmUj002303; Fri, 23 Oct 2009 10:22:48 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1256311368; bh=letYRlheGPYq6r5H3Kf8cddJ99vtxskY/t8q3tm8Juo=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=tVkb1l7MJpI3LYYRCp+dxk28/PBZTTinkHhGAqcoIeU5i9Cgds3l3e2uIGn1IchBu K+3mC93gKRgyjGX+BQ2+H9IC96XGqBddTc76y+ZWZjD5ALy7Hh/nMaNjcDrKCw+Ig9 B+OYGhsziSI1GU93gQAouQnOWJ0NrgpZjVSjKjtE= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n9NFMlE3002301; Fri, 23 Oct 2009 10:22:47 -0500 (CDT) (envelope-from tinguely) Date: Fri, 23 Oct 2009 10:22:47 -0500 (CDT) From: Mark Tinguely Message-Id: <200910231522.n9NFMlE3002301@casselton.net> To: freebsd-arm@freebsd.org, ray@dlink.ua, tinguely@casselton.net In-Reply-To: <20091023155825.381728f4.ray@dlink.ua> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Fri, 23 Oct 2009 10:22:48 -0500 (CDT) Cc: Subject: Re: [ARM+NFS] panic while copying across NFS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 15:22:54 -0000 > Hi Mark! > With your patch works fine. > > # dd if=/swap.file of=/mnt/swap.file bs=1M > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 231.294150 secs (4642322 bytes/sec) > > But still slow. Maybe someone know why slow? (Marvell 88F5182 rev A2) Here is what I think is the complete update to the revisions 181296 and 195779 cache fixes. 1) vm_machdep.c: remove the dangling allocations so they do not un-necessarily turn off the cache in the future. (this is the patch that worked for you. 2-3 are two more) 2) busdma_machdep.c: remove the same amount than shadow mapped. 3) pmap.c: PVF_REF is used to invalidate cache and flush tlb. PVF_REF is set by a trap when the page is really use. kernel pages should assume it is immediately used. In ARMv5 pmap, we should manage every RAM physical page. Without a profiling the kernel, it would be tough to say were performance issues are orginating. (device driver, in the fs code, or machine level). Ideas about the machine level code: I think freeing the memory from the level page table descriptors for general use should improve things. More usuable RAM is always a good thing. There is some code in trap and other places that looks to see if the level 1 pde is for this memory space or shared memory space. we can keep a few level pde around for forks. downside a fork could fail the 16K contig buffer; which it can in other archs too. This is a pretty big change. There are tests/fixes (switch/pmap) for low vector page that can be removed with define statement for high vector kernels. In fact if we are not sharing the level 1 pd, this set only in pmap initialization. Simple change "#ifdef LOW_VECTOR", minor savings. Are we cleaning caches too much? ARMv6/7 will be a big game changer. Should put a ton of effort into ARMv5, put the effort into optimizing, or do both? Index: arm/arm/vm_machdep.c =================================================================== --- arm/arm/vm_machdep.c (revision 198246) +++ arm/arm/vm_machdep.c (working copy) @@ -169,6 +169,9 @@ sf_buf_free(struct sf_buf *sf) if (sf->ref_count == 0) { TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); nsfbufsused--; + pmap_kremove(sf->kva); + sf->m = NULL; + LIST_REMOVE(sf, list_entry); if (sf_buf_alloc_want > 0) wakeup_one(&sf_buf_freelist); } @@ -449,9 +452,12 @@ arm_unmap_nocache(void *addr, vm_size_t size) size = round_page(size); i = (raddr - arm_nocache_startaddr) / (PAGE_SIZE); - for (; size > 0; size -= PAGE_SIZE, i++) + for (; size > 0; size -= PAGE_SIZE, i++) { arm_nocache_allocated[i / BITS_PER_INT] &= ~(1 << (i % BITS_PER_INT)); + pmap_kremove(raddr); + raddr += PAGE_SIZE; + } } #ifdef ARM_USE_SMALL_ALLOC Index: arm/arm/busdma_machdep.c =================================================================== --- arm/arm/busdma_machdep.c (revision 198246) +++ arm/arm/busdma_machdep.c (working copy) @@ -649,7 +649,8 @@ bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, b KASSERT(map->allocbuffer == vaddr, ("Trying to freeing the wrong DMA buffer")); vaddr = map->origbuffer; - arm_unmap_nocache(map->allocbuffer, dmat->maxsize); + arm_unmap_nocache(map->allocbuffer, + dmat->maxsize + ((vm_offset_t)vaddr & PAGE_MASK)); } if (dmat->maxsize <= PAGE_SIZE && dmat->alignment < dmat->maxsize && Index: arm/arm/pmap.c =================================================================== --- arm/arm/pmap.c (revision 198246) +++ arm/arm/pmap.c (working copy) @@ -1643,7 +1643,7 @@ pmap_enter_pv(struct vm_page *pg, struct pv_entry /* PMAP_ASSERT_LOCKED(pmap_kernel()); */ pve->pv_pmap = pmap_kernel(); pve->pv_va = pg->md.pv_kva; - pve->pv_flags = PVF_WRITE | PVF_UNMAN; + pve->pv_flags = PVF_WRITE | PVF_UNMAN | PVF_REF; pg->md.pv_kva = 0; TAILQ_INSERT_HEAD(&pg->md.pv_list, pve, pv_list); @@ -2870,7 +2870,7 @@ pmap_kenter_internal(vm_offset_t va, vm_offset_t p vm_page_lock_queues(); PMAP_LOCK(pmap_kernel()); pmap_enter_pv(m, pve, pmap_kernel(), va, - PVF_WRITE | PVF_UNMAN); + PVF_WRITE | PVF_UNMAN | PVF_REF); pmap_fix_cache(m, pmap_kernel(), va); PMAP_UNLOCK(pmap_kernel()); } else { @@ -3538,7 +3538,7 @@ do_l2b_alloc: if (!TAILQ_EMPTY(&m->md.pv_list) || m->md.pv_kva) { KASSERT(pve != NULL, ("No pv")); - nflags |= PVF_UNMAN; + nflags |= PVF_UNMAN | PVF_REF; pmap_enter_pv(m, pve, pmap, va, nflags); } else m->md.pv_kva = va; From owner-freebsd-arm@FreeBSD.ORG Fri Oct 23 16:03:55 2009 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 59ADF1065694 for ; Fri, 23 Oct 2009 16:03:55 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 449B18FC08 for ; Fri, 23 Oct 2009 16:03:55 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KRZ000QV5YG1280@asmtp026.mac.com> for freebsd-arm@freebsd.org; Fri, 23 Oct 2009 09:03:52 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <200910231522.n9NFMlE3002301@casselton.net> Date: Fri, 23 Oct 2009 09:03:52 -0700 Message-id: References: <200910231522.n9NFMlE3002301@casselton.net> To: Mark Tinguely X-Mailer: Apple Mail (2.1076) Cc: freebsd-arm@freebsd.org Subject: Re: [ARM+NFS] panic while copying across NFS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 16:03:55 -0000 On Oct 23, 2009, at 8:22 AM, Mark Tinguely wrote: > 3) pmap.c: PVF_REF is used to invalidate cache and flush tlb. PVF_REF > is set by a trap when the page is really use. kernel pages should > assume it is immediately used. This causes problems for me, so I don't think this is quite right. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arm@FreeBSD.ORG Fri Oct 23 16:41:25 2009 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 1BAD2106566B for ; Fri, 23 Oct 2009 16:41:25 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id CB4B08FC1E for ; Fri, 23 Oct 2009 16:41:24 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n9NGfNBO006722; Fri, 23 Oct 2009 11:41:23 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1256316083; bh=mJOe0eypJs5POe8KIlCljyS5NS8NZ59aWRjcJQdkdJk=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=gWbZgbGOn4Ix5po6obFEa4AIRayULtV+9EwCLQjgkAohRA9RHi4Dnz7o9EiD8SP0D cl4awZGFO/Y+OK7XHBMa5k1jutZuDJdE27Yf0L//LcH63izLq2+hhZJiOmWxic2YY9 K+r/TBDo7L2UgfKQnAWtNLJwcDJvI69LzZFmjgzY= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n9NGfN1a006721; Fri, 23 Oct 2009 11:41:23 -0500 (CDT) (envelope-from tinguely) Date: Fri, 23 Oct 2009 11:41:23 -0500 (CDT) From: Mark Tinguely Message-Id: <200910231641.n9NGfN1a006721@casselton.net> To: tinguely@casselton.net, xcllnt@mac.com In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Fri, 23 Oct 2009 11:41:23 -0500 (CDT) Cc: freebsd-arm@freebsd.org Subject: Re: [ARM+NFS] panic while copying across NFS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 16:41:25 -0000 > > On Oct 23, 2009, at 8:22 AM, Mark Tinguely wrote: > > > 3) pmap.c: PVF_REF is used to invalidate cache and flush tlb. PVF_REF > > is set by a trap when the page is really use. kernel pages should > > assume it is immediately used. > > This causes problems for me, so I don't think this is quite right. > FYI, > > -- > Marcel Moolenaar > xcllnt@mac.com Thank-you for the information. Hmmm, how odd. I will give that some thought. To everyone else, I read my last post and a big sorry for incomplete sentences. It was just a quick list of things that could be changed to streamline the machine dependant portion of the code. --Mark Tinguely. From owner-freebsd-arm@FreeBSD.ORG Fri Oct 23 16:48:41 2009 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 E62DF106566C for ; Fri, 23 Oct 2009 16:48:41 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id D2AB78FC0C for ; Fri, 23 Oct 2009 16:48:41 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp027.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KRZ00BKC80CJWA0@asmtp027.mac.com> for freebsd-arm@freebsd.org; Fri, 23 Oct 2009 09:48:20 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <200910231641.n9NGfN1a006721@casselton.net> Date: Fri, 23 Oct 2009 09:48:12 -0700 Message-id: <0C359698-59A4-4213-BC22-9F1483611EB5@mac.com> References: <200910231641.n9NGfN1a006721@casselton.net> To: Mark Tinguely X-Mailer: Apple Mail (2.1076) Cc: freebsd-arm@freebsd.org Subject: Re: [ARM+NFS] panic while copying across NFS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 16:48:42 -0000 On Oct 23, 2009, at 9:41 AM, Mark Tinguely wrote: > >> >> On Oct 23, 2009, at 8:22 AM, Mark Tinguely wrote: >> >>> 3) pmap.c: PVF_REF is used to invalidate cache and flush tlb. >>> PVF_REF >>> is set by a trap when the page is really use. kernel pages should >>> assume it is immediately used. >> >> This causes problems for me, so I don't think this is quite right. >> FYI, >> >> -- >> Marcel Moolenaar >> xcllnt@mac.com > > Thank-you for the information. Hmmm, how odd. I will give that some > thought. > > To everyone else, I read my last post and a big sorry for incomplete > sentences. > It was just a quick list of things that could be changed to > streamline the > machine dependant portion of the code. Also to everyone: There's a huge amount of instability in the ARM VM/PMAP code. Things are slightly better when the L2 cache is configured for write-through, but there's at least 2 issues left: 1. Clustered I/O causes incoherency and pretty much makes the box useless when you want to run what you just built. 2. PMAP panics in one or two places, typically after a few minutes/hours of uptime when doing builds. With a L2 cache the problems are a bit more severe as it adds I-cache incoherency to the mix, which even prevents running init(8). I think w e need to rethink the PMAP layer, because if we keep trying to patch it, performance will probably worse from what it is now. Plus, we'll have to deal with physically indexed and physically tagged caches ASAP, so better modularization helps. FYI, -- Marcel Moolenaar xcllnt@mac.com