Re: [RFC][patch] NAND partial page read functionality

["Jörn Engel" <joern@logfs.org>]

On Tue, 18 December 2007 10:48:51 +0200, Artem Bityutskiy wrote:
> 
> Well, this depends. If an MTD user wants to write 4KiB, and issues 4KiB
> write request, then it is of course faster to write 2x2048, then 8x512,
> and it is even faster to do some kind of multi-page write (some old
> flashes had this AFAIK).

Not necessarily.  The alauda chip has a "page program" and a "block
program" command.  With a naive implementation the block program is
faster.  But when doing asynchronous transfers on the usb bus, page
program becomes just as fast.  In this particular case, block program
can only reduce the number of synchronous bus latencies for a
non-optimized implementation.

> But surely if the driver is not dumb, it will do 2x2048?
> 
> I've glanced at jffs2_flash_writev(), and it seems it is also not dumb -
> if in needs to write a 4KiB buffer, it first finishes current
> write-buffer, flushes it, then it calles mtd->write() for multiple min.
> I/O units (note, it does not use wbuf now), and only the rest, which
> does not comprise whole min. I/O unit, goes to the wbuf.
> 
> Thus, I'd conclude, JFFS2 should benefit.

If writesize is 256 and pagesize is 2048, every wbuf flush will write
exactly 256.  Any remaining clean multiple of 256 is written directly,
but this will rarely be an aligned clean multiple of 2048.  Every wbuf
flush ensures that either the previous or the following writes is not.

As long as JFFS2 and MTD are synchronous, this could be a significant
performance hit.

Jörn

-- 
Mac is for working,
Linux is for Networking,
Windows is for Solitaire!
-- stolen from dc