NAND: Improve read performance from Large Page NAND devices

Improve read performance from Large Page NAND devices.

This patch produces a ~31% improvement in oob_first read speed (on a 300MHz ARM9). The time for a mid-buffer 2k page read is now 293us, 6.99MB/s (was 385us, 5.31MB/s). oob_first is probably the best case improvement.

---

Dear Nick Thompson,

I tested this on mpc5121ads (sector size 128 KiB) and sequoia (sector size 16 KiB).

The patch applied not cleanly against "master" (but was easy to fix).

However, I did not notice any changes to the speed for a "nand read" at all.

Is this not the right flash types, or not thr right type of test?

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The Gates in my computer are AND, OR and NOT; they are not Bill.

Hi Wolfgang,

Thanks for testing this. I think this has worked as I would have hoped. Your test is fine. I use "nand read" and make measurements on a mixed signal 'scope.

On the mpc5121ads, mpc5121_nfc.c is used which defines its own command function. This function always waits for read commands to complete and the config file doesn't define the CONFIG_NAND_READ_CMD_NO_WAIT config (and in this case it can't) so the read should behave more or less identically.

[Possibly the command function could be changed to not wait for read to complete...]

On Sequoia, ndfc.c is used which appears to use the default command functions. If the sector size is 16kBytes I assume this is a small page NAND device and you should see no change at all. If it was a large page device you would also see no difference, unless the config file set CONFIG_NAND_READ_CMD_NO_WAIT, in which case the read_page function for H/W ECC, should fetch the next page in parallel to doing ECC correction, leading to an improvement in performance.

All in all your tests was very successful, and though I left you disappointed this time, from my point of view I'm very pleased :)

Thanks,
Nick.

Dear Nick Thompson,

Also tested on Canyonlands (460EX); here I actually see a slightj improvement (5.5% faster, i. e. time to read 126 MB from NAND goes down from 28.8 to 27.2 seconds (4.4 -> 4.6 MiB/s).

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Any time things appear to be going better, you have overlooked  some-
thing.

Hi Wolfgang,

Thanks again.

It seems the raw page data transfer rate is quite low on that board. The patch saves time between page data transfers, so the percentage improvement seen is better if you can get the page data out quicker.

The default read_buf (and write_buf) in nand_base.c are safe, but slow. I put in davinci specific optimised versions (DMA or multibyte read ticks might be used) to double my raw transfer rate. Without that, my measurements would show ~15% improvement only.

In total on da830evm I'm getting a >300% speed improvement. 1.69MB/s changes to 6.99MB/s. (5.31MB/s without this patch.)

Nick.

What kind of CPU usage are you seeing? I am throughput of ~1.9MBs for writes on a Samsung K9WBG08U1M 4GB with 4K page but with high cpu usage.

View this message in context: http://old.nabble.com/-U-Boot---PATCH-RFC--NAND%3A-Improve-read-performance-from-Large-Page%09NAND-devices-tp26695701p27186018.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

I'm not sure what you are asking here. There is no idle loop to measure so CPU is running at 100%.

The code does poll the NAND device for data ready, but in my case the NAND loads its cache faster than the CPU can finish sorting out ECC checks (despite ECC H/W assistance). The result is the CPU never actually on the NAND.

This patch (not yet formally submitted) removes this potential waiting time that was present - plus some redundant command sequences due to incorrect function levelling. Most of my performance gain comes from optimising the data transfer (to and) from the NAND - see drivers/mtd/nand/davinci_nand.c
- which is already in the mainline.

Apologies if that doesn't answer your question.

Nick.

I hadn't dug into it yet to find the polling behavior but like you said with no idle the CPU. It was just different behavior from what I see with the SD which is some CPU time spent waiting on I/O (maybe because of the DMA vs polling).

I did find a few of simple optimizations that gained me ~1MBs increase on NAND and SD as well.
- /proc/sys/vm/dirty_expire_centiseconds = 2
- /proc/sys/vm/dirty_background_ratio = 5
- Unchecked KConfig "Optimize for size" which was enabled by default.

Thanks for your feedback.

Appareo Systems, LLC
1810 NDSU Research Circle N
Fargo, ND 58102

JOSH GELINSKE
FIRMWARE ENGINEERING MANAGER

Appareo Systems, LLC
1810 NDSU Research Circle N
Fargo, ND 58102
P: (701) 356-2200 Ext 251
C: (701) 306-0899
F: (701) 356-3157

http://www.appareo.com
jgelinske at appareo.com

NOTICE: This message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2521, is CONFIDENTIAL and may also be protected by ATTORNEY-CLIENT OR OTHER PRIVILEGE. If you believe that it has been sent to you in error, do not read it. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error and then delete it.

-----Original Message-----
From: Nick Thompson [mailto:nick.thompson at ge.com]
Sent: Monday, January 18, 2010 6:48 AM
To: Josh Gelinske
Cc: u-boot at lists.denx.de
Subject: Re: [U-Boot] [PATCH RFC] NAND: Improve read performance from Large Page NAND devices

writes

I'm not sure what you are asking here. There is no idle loop to measure so
CPU is running at 100%.

The code does poll the NAND device for data ready, but in my case the NAND
loads its cache faster than the CPU can finish sorting out ECC checks (despite ECC H/W assistance). The result is the CPU never actually on the
NAND.

This patch (not yet formally submitted) removes this potential waiting time
that was present - plus some redundant command sequences due to incorrect
function levelling. Most of my performance gain comes from optimising the
data transfer (to and) from the NAND - see drivers/mtd/nand/davinci_nand.c
- which is already in the mainline.

Apologies if that doesn't answer your question.

Nick.