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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
