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/
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.