linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Tim Harvey <tharvey@gateworks.com>, linux-mtd@lists.infradead.org
Subject: Re: ubi/ubifs performance comparison on two NAND devices
Date: Wed, 27 Feb 2019 23:59:18 +0100	[thread overview]
Message-ID: <1778492.l5RC12KMDO@blindfold> (raw)
In-Reply-To: <CAJ+vNU1xtj3f7GefcyY=s7RmNxtBjFpefaG57Xmeq80w0=monQ@mail.gmail.com>

Tim,

Am Mittwoch, 27. Februar 2019, 23:43:17 CET schrieb Tim Harvey:
> On Wed, Feb 27, 2019 at 2:13 PM Richard Weinberger
> <richard.weinberger@gmail.com> wrote:
> >
> > On Wed, Feb 27, 2019 at 9:39 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > >
> > > 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

Here you say attach takes 7 times longer.

> > > '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?
> >
> > Let's focus as first step on UBI attach by scanning. Here UBI reads
> > the first two
> > (sub)pages of each block.
> >
> > Please figure whether in both setup subpages are used or not. Then
> > measure how long
> > it takes to read a single page.
> > Given this numbers we can start with the detective work.
> >
> 
> Hi Richard,
> 
> I suppose I should have provided:
> 
> [    6.438793] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xd5
> [    6.445240] nand: Micron MT29F16G08ADACAH4
> [    6.449362] nand: 2048 MiB, SLC, erase size: 256 KiB, page size:
> 4096, OOB size: 224
> [    6.459037] Scanning device for bad blocks
> [    8.784007] 3 fixed-partitions partitions found on MTD device gpmi-nand
> [    8.790716] Creating 3 MTD partitions on "gpmi-nand":
> [    8.795823] 0x000000000000-0x000001000000 : "uboot"
> [    8.810841] 0x000001000000-0x000001100000 : "env"
> [    8.819356] 0x000001100000-0x000080000000 : "rootfs"
> [    9.355834] gpmi-nand 112000.gpmi-nand: driver registered.
> 
> and
> 
> [    6.014529] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xd5
> [    6.020907] nand: AMD/Spansion S34ML16G2
> [    6.024917] nand: 2048 MiB, SLC, erase size: 128 KiB, page size:
> 2048, OOB size: 128
> [    6.033385] Scanning device for bad blocks
> [   10.689345] 3 fixed-partitions partitions found on MTD device gpmi-nand
> [   10.696056] Creating 3 MTD partitions on "gpmi-nand":
> [   10.701143] 0x000000000000-0x000001000000 : "uboot"
> [   10.720392] 0x000001000000-0x000001100000 : "env"
> [   10.729253] 0x000001100000-0x000080000000 : "rootfs"
> [   11.793715] gpmi-nand 112000.gpmi-nand: driver registered.
> 
> So its taking 2.3s to scan the Micron and 5.4s to scan the Cypress
> which is what I would expect (Micron 2x faster as it has similar read
> time per block but half as many blocks)

And now all is good.
I'm confused.

> > Did you also check what timings both NANDs are using?
> 
> No, where would I see these? Would this be something that can be
> provided in device-tree or a nand chip-specific driver?

Usually the driver computes them based on various sources.
See drivers/mtd/nand/raw/nand_timings.c

Thanks,
//richard




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

  reply	other threads:[~2019-02-27 22:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-27 20:39 ubi/ubifs performance comparison on two NAND devices Tim Harvey
2019-02-27 22:12 ` Richard Weinberger
2019-02-27 22:43   ` Tim Harvey
2019-02-27 22:59     ` Richard Weinberger [this message]
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=1778492.l5RC12KMDO@blindfold \
    --to=richard@nod.at \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tharvey@gateworks.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;
as well as URLs for NNTP newsgroup(s).