Re: ubi/ubifs performance comparison on two NAND devices

Richard Weinberger
2019-02-27T22:59:28Z

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