From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5585 invoked by alias); 15 Oct 2009 04:41:28 -0000 Received: (qmail 5575 invoked by uid 22791); 15 Oct 2009 04:41:26 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from virtual.bogons.net (HELO virtual.bogons.net) (193.178.223.136) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Oct 2009 04:41:22 +0000 Received: from jifvik.dyndns.org (jifvik.dyndns.org [85.158.45.40]) by virtual.bogons.net (8.10.2+Sun/8.11.2) with ESMTP id n9F4fJ419071; Thu, 15 Oct 2009 05:41:19 +0100 (BST) Received: from [172.31.1.126] (neelix.jifvik.org [172.31.1.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jifvik.dyndns.org (Postfix) with ESMTP id 1196D3FEB; Thu, 15 Oct 2009 05:41:19 +0100 (BST) Message-ID: <4AD6A7EC.8080703@jifvik.org> Date: Thu, 15 Oct 2009 04:41:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) MIME-Version: 1.0 To: Rutger Hofman Cc: =?ISO-8859-1?Q?J=FCrgen_Lambrecht?= , Ross Younger , eCos developers , Deroo Stijn Subject: Re: NAND technical review References: <4ACB4B58.2040804@ecoscentric.com> <4ACC61F0.3020303@televic.com> <4AD3E92E.5020301@jifvik.org> <4AD47ADE.9010606@cs.vu.nl> In-Reply-To: <4AD47ADE.9010606@cs.vu.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-10/txt/msg00022.txt.bz2 Rutger Hofman wrote: > Jonathan Larmour wrote: > [snip] > >>> We also prefer R's model of course because we started with R's model >>> and use it now. >> >> >> You haven't done any profiling by any luck have you? Or code size >> analysis? Although I haven't got into the detail of R's version yet >> (since I was starting with dissecting E's), both the footprint and the >> cumulative function call and indirection time overhead are concerns of >> mine. > > > In a first step in mitigating the 'footprint pressure', I have added CDL > options to configure in/out support for the various chips types, to wit: > - ONFI chips; > - 'regular' large-page chips; > - 'regular' small-page chips. > It is in r678 on my download page > (http://www.cs.vu.nl/~rutger/software/ecos/nand-flash/). As I had > suggested before, this was a very small refactoring (although code has > moved about in io_nand_chip.c to save on the number of #ifdefs). I'm sure that's useful. > One more candidate for a reduce in code footprint: I can add a CDL > option to configure out support for heterogeneous controllers/chips. The > ANC layer will become paper-thin then. If this change will make any > difference, I will do it within, say, a week's time. I wouldn't want you to spend time until the decision's made. I'll make a note that it would take a week to do. Admittedly, I'm not sure the savings would be enough to make it "paper-thin". > As regards the concerns for (indirect) function call overhead: my > intuition is that the NAND operations themselves (page read, page write, > block erase) will dominate. It takes 200..500us only to transfer a page > over the data bus to the NAND chip; one recent data sheet mentions > program time 200us, erase time 1.5ms. I think only a very slow CPU would > show the overhead of less than 10 indirect function calls. I think it's more the cumulative effect, primarily on reads. Especially as there's no asynchronous aspect - the control process is synchronous, so any delays between real underlying NAND operations only add up. Ross quoted an example of about 25us for a page read. Off the top of my head, for something like a 64MHz CPU with 4 clock ticks per instruction on average, that's 16 insns per us, so a page read is about equivalent to 400 insns. At that sort of level I'm not sure overheads are lost in the noise. Maybe I've messed up those guestimates though. I wonder if Ross has any performance data for E he could contribute? On a separate point, while I'm here, I think the use of printf via cyg_nand_global.pf would want tidied up a lot. Some of them seem to be there to mention errors to the user, but without any programmatic treatment of the errors, primarily reporting them to higher layers. It should also be possible to eliminate the overheads of the printf. Right now there's quite a lot of them, involving function calls, allocation of const string data, and occasionally calculation of arguments, even if the pf function pointer is pointing to an empty null printf function. It should be possible to turn them off entirely, and not be any worse off for it (including error reporting back up to higher layers). It might not be so bad if the strings were a lot shorter, or the printf functions less frequently used, but being able to turn them off entirely would seem better. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine