From: Ryan Thompson <i@ry.ca>
To: massimo cirillo <maxcir@gmail.com>
Cc: linux-mtd@lists.infradead.org, Massimo.CIRILLO@numonyx.com
Subject: Re: JFFS2 errors on ppc-4xx with CFI NOR flash
Date: Fri, 5 Mar 2010 15:22:21 -0600 [thread overview]
Message-ID: <56a87efc1003051322td74992cide1ca01776c24646@mail.gmail.com> (raw)
In-Reply-To: <56a87efc1003050936j57e8d879q70855a5724fa3be9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]
I also created the attached gnuplot graph showing the time taken to
write 128KiB files versus the filesystem utilization. Note that the
underlying partition size is 32128KiB.
In case attachments don't work on linux-mtd, the graph is also hosted
at http://ry.ca/clients/jffs2-128KiB.png
- R
On Fri, Mar 5, 2010 at 11:36 AM, Ryan Thompson <i@ry.ca> wrote:
> On Fri, Mar 5, 2010 at 3:56 AM, massimo cirillo <maxcir@gmail.com> wrote:
>> I suppose you don't have CONFIG_MTD_XIP enabled.
>> So in order to completely disable the suspend,
>> please in chip_ready() function just after "case FL_ERASING:"
>> (line 775) put the line "goto sleep;" and repeat your test.
>> Let me know.
>
> By skipping the FL_ERASING case as you suggested, my test now
> completes successfully without any INFO-or-higher kernel messages.
>
> However, it still takes a very long time. The initial files are
> written out quickly (subjectively, performance seems similar to raw
> mtd speed). However, after 50% or so, performance begins to degrade
> dramatically. At 65%, a 256KiB file takes 11 sec to write. At 75%, 20
> sec. 90%, 38 sec. 95%, 77 sec. 99%, 121 sec. The entire test took 28.4
> minutes to go from 3%-100% on the ~32MiB partition.
>
> Performance seems somewhat consistent with my previous result:
>
>> 2010/3/4 Ryan Thompson <i@ry.ca>:
>>> The errors continued until the filesystem actually reported 100% full
>>> and my script terminated. The entire 3%-100% operation took about 21
>>> minutes for <32MiB, and was definitely much slower towards the end
>>> with all the errors.
>
> I've done a flash_eraseall -j followed by a reboot before each run.
>
> I also benchmarked the mtdblock performance without JFFS2 (also
> getting input from urandom):
>
> # time dd if=/dev/urandom of=/dev/mtdblock16
> dd: writing '/dev/mtdblock16': No space left on device
> 64257+0 records in
> 64256+0 records out
> Command exited with non-zero status 1
> real 5m 30.17s
> user 0m 0.08s
> sys 1m 2.66s
> # perl -le 'printf("bytes written = 0x%08x\n", 64256 * 512);'
> bytes written = 0x01f60000
> # grep modules /proc/mtd
> mtd16: 01f60000 00020000 "modules"
>
> - R
>
[-- Attachment #2: jffs2-128KiB.png --]
[-- Type: image/png, Size: 25497 bytes --]
next prev parent reply other threads:[~2010-03-05 21:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-04 18:25 JFFS2 errors on ppc-4xx with CFI NOR flash Ryan Thompson
2010-03-04 20:16 ` massimo cirillo
[not found] ` <D47DD163F8914C69B534C8AA8FF3258F@WINXP>
2010-03-04 20:33 ` Ryan Thompson
2010-03-04 22:01 ` Ryan Thompson
2010-03-05 9:56 ` massimo cirillo
2010-03-05 17:36 ` Ryan Thompson
2010-03-05 21:22 ` Ryan Thompson [this message]
2010-03-06 15:22 ` Joakim Tjernlund
2010-03-08 11:24 ` massimo cirillo
2010-03-08 17:35 ` Ryan Thompson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56a87efc1003051322td74992cide1ca01776c24646@mail.gmail.com \
--to=i@ry.ca \
--cc=Massimo.CIRILLO@numonyx.com \
--cc=linux-mtd@lists.infradead.org \
--cc=maxcir@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox