[Yaffs] JFFS2 -vs- YAFFS2 performance (Was: inadvertently marking all blo cks bad?)

[Charles Manning]

On Tuesday 12 July 2005 10:48, Lawson.Reed wrote:
> > > This is so FAST compared to JAFFS2. THANK YOU!!!!!
> >
> > Do you have any numbers/examples for how the two compare?
> >
> > Wookey
>
> Once I saw how it took 22 minutes for my ColdFire system to boot
> a JFFS2 file system, I about freaked. Once I switched to YAFFS2,
> my system boots in about 6 seconds. It is a godsend. It's the only
> way to go with these big flash parts.

Thanx for the feedback. We don't really get enough, except when things are 
broken :-).
>
> As far as system read and write times, they were about the same
> because they both used the same underlying MTD ECC code.
> Its about 110 KBytes/sec for write and 205 KBytes/sec read.
> That's with FTP over Ethernet. The bottle neck seems to be
> that software ECC code. Not sure what to do about that.

That's very slow, but I guess you're somewhat limited by CPU speed.

You might try the yaffs_ecc.c code isntead of nand_ecc.c.  yaffs_ecc.c is 
approx 15% faster (mileage will vary).

A hand-tuned set of NAND access functions in the mtd could help. For example 
in ARM you can sometimes use ldm/stm instructions to shift the data faster 
than a for loop.  You could also get some speed up by combining the ECC with 
the read/writes.

>
> My system looks like this:
>    o Motorola (oh, Freescale, excuse me) MCF5272 66 MHz
>    o 2 x Samsung K9W8G08U1M 512K x 8 Bit NAND Flash
To be pedantic, those are 512M x 8 bit (ie. 512MByte) parts.
>    o 32 Meg RAM.
>    o 1 Meg boot flash.
>    o uClinux 2.4.24
>    o MTD from 2.6 tree (back ported)
>    o YAFFS2 from 2.6 tree (back ported)

There are some more speedups wrt better garbage collection tht I currently 
have in test and should check in later this week. These really only have 
impact when the flash gets full.

Another thing that is material is that with larger flashes the "chunk groups" 
get larger so YAFFS needs to search further (see 
yaffs_guts.c:yaffs_FindChunkInGroup()). A 1Gbyte system has 512K (==2^^19 
bits)  pages. Since Tnodes only hold 16 bit entries, each chunk group handles 
the last 3 bits and is there are 8 chunks per chunk group. It is relatively 
simple, but not trivial, to increase the size of Tnodes to a wider value and 
thus reduce (or eliminate) chunk group searching. This is on the Todo.


Charles