Re: Benchmarking: POP flash vs. MMC?

[Artem Bityutskiy <dedekind@yandex.ru>]

David Hagood wrote:
> Well, that's not what I would have expected - I would have thought
> reads on POP would have been faster than that, and cheaper - the SD
> being the same speed but less CPU is surprising.

1. As Russ and David said, OneNAND driver does not really
use DMA, because the I/O is done in 2K chunks, and this
is just too small piece of data for DMA.

2. UBIFS also compresses data on-the-flight. You may try
disabling it and see what changes, but probably not
too much, because of the way the driver writes (no DMA).
Try mounting with 'compre=none' option, see here:

http://www.linux-mtd.infradead.org/doc/ubifs.html#L_mountopts

BTW, some compression testing results may be found here:

http://www.linux-mtd.infradead.org/misc/misc.html#L_ubifs_compr

although they are not 100% relevant for this case.

3. UBIFS provides you greater data reliability. E.g., it
CRCs all data (see here
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_checksumming)
OneNAND was very reliable last time we tested it, and we
disable _some_ CRC checking for it. Try to use the
'no_chk_data_crc' and get better read speed.

4. UBIFS has 'bulk read' feature which works well on OneNAND,
(see here: http://www.linux-mtd.infradead.org/doc/ubifs.html#L_readahead)
Try to enable it as well. You should end up with faster
read speed.

5. Last but not least, UBIFS+OneNAND provides just another
level of reliability, comparing to SD. In general, SDs are
not very good for storing system libraries, etc. I tried to
summarize this at some point here:

http://www.linux-mtd.infradead.org/doc/ubifs.html#L_raw_vs_ftl

HTH.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html