Re: ubi/ubifs performance comparison on two NAND devices

[Tim Harvey <tharvey@xxxxxxxxxxxxx>]

On Wed, Feb 27, 2019 at 2:13 PM Richard Weinberger
<richard.weinberger@xxxxxxxxx> wrote:
>
> On Wed, Feb 27, 2019 at 9:39 PM Tim Harvey <tharvey@xxxxxxxxxxxxx> 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
> > '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)

> 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?

Currently I'm just relying on CFI... the 4.20 kernel I'm testing with
has the following enabled:
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_DATAFLASH=y
CONFIG_MTD_M25P80=m
CONFIG_MTD_SST25L=y
CONFIG_MTD_NAND_CORE=m
CONFIG_MTD_NAND_ECC=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_GPMI_NAND=y
CONFIG_MTD_SPI_NAND=m
CONFIG_MTD_SPI_NOR=m
CONFIG_MTD_MT81xx_NOR=m
CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y
CONFIG_SPI_FSL_QUADSPI=m
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
CONFIG_MTD_UBI_FASTMAP=y
CONFIG_MTD_UBI_BLOCK=y

Thanks,

Tim

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