linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Tim Harvey <tharvey@gateworks.com>
To: linux-mtd@lists.infradead.org
Subject: ubi/ubifs performance comparison on two NAND devices
Date: Wed, 27 Feb 2019 12:39:25 -0800	[thread overview]
Message-ID: <CAJ+vNU3sxjVjuPg8NRCBJzRNByM__xFAYdiQo=-ZKXawvZw1yQ@mail.gmail.com> (raw)

Greetings,

I've got two embedded boards (IMX6 using gpmi-nand driver) that are
identical except for the NAND FLASH and am trying to understand why
I'm seeing a massive performance difference when it comes to ubi and
ubifs (in particular ubi scanning and UBIFS resizing).

Micron MT29F16G08ADACAH4:
- page size: 4320 bytes (4096 + 224 bytes)
- block size: 64 pages (256K + 14K bytes)
- device size: 16Gb
- 30ns per-block read
- 300us per-block program
- 2.0ms per-block erase

Cypress S34ML16G202BHI000
- page size: 2176 bytes (2048+128)
- block size: 64 pages (128K + 8K)
- device size: 16Gb
- 25ns per-block read
- 300us per-block program
- 3.5ms per-block erase

The parts are relatively close in per-block performance but because
the Micron has twice the block size I think of it being twice as fast
on a per-byte basis compared to the Cypress and I do see this relative
performance when testing read/write/erase both in modern U-Boot and
latest Linux. What doesn't add up is that the Cypress part takes about
7x longer to complete the ubi attach (between 'attaching mtd' and
'scanning is finished' and about 100x longer to complete the UBIFS
free space fixup (between 'start fixing up free space' and 'free space
fixup complete') performed on the first mount of a ubifs filesystem
that was created with auto-resize enabled.

Both parts are 2GiB and the ubi scanning on attach in the kernel goes
from ~4s on Micron to ~28s on Cypress and the UBIFS free space fixup
goes from 0.5s on Micron to a whopping 56s on Cypress.

Any ideas why would I be seeing this kind of performance difference
when the raw erase/read/write performance is (both datasheet and Linux
tests) only 2x slower? Anywhere I can look to improve performance of
the Cypress part?

Best Regards,

Tim

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

             reply	other threads:[~2019-02-27 20:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-27 20:39 Tim Harvey [this message]
2019-02-27 22:12 ` ubi/ubifs performance comparison on two NAND devices Richard Weinberger
2019-02-27 22:43   ` Tim Harvey
2019-02-27 22:59     ` Richard Weinberger
2019-02-28 16:40       ` Tim Harvey
2019-02-28 17:21         ` Steve deRosier
2019-03-01 16:41           ` Tim Harvey
2019-03-01 16:44             ` Richard Weinberger

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='CAJ+vNU3sxjVjuPg8NRCBJzRNByM__xFAYdiQo=-ZKXawvZw1yQ@mail.gmail.com' \
    --to=tharvey@gateworks.com \
    --cc=linux-mtd@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).