public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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 11:36:32 -0600	[thread overview]
Message-ID: <56a87efc1003050936j57e8d879q70855a5724fa3be9@mail.gmail.com> (raw)
In-Reply-To: <62cbdcd91003050156g404106a5pfdf10bb29d9ce837@mail.gmail.com>

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

  reply	other threads:[~2010-03-05 17:36 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 [this message]
2010-03-05 21:22           ` Ryan Thompson
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=56a87efc1003050936j57e8d879q70855a5724fa3be9@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