Write performance patch

[Savin Zlobec]

I was doing a bit of profiling and noticing an unusual amount of
reads while running a simple file append loop. The reads come
from:

1) uffs_FlashCheckErasedBlock, which is fine, but I don't really
expect my blocks to be 'unclean' except if there was an power fail
in the middle of erase op. In which case I am reluctant to trust
100% a simple 0xFF check to tell me if the block erase was good.
There are other ways to ensure this doesn't happen or at least
detect that it did and which block was affected. I would like to
have dev->ops->CheckErasedBlock and let the flash driver decide if
the block is clean. If the driver doesn't define the op, than we run
the 0xFF test - what do you think?

2) After a clean block is taken from erased list, spares are reread
again by uffs_BlockInfoLoad(UFFS_ALL_PAGES). The attached patch
addresses this by adding uffs_BlockInfoInitErased() function which
initializes a clean block info for a given erased block.

[Ricky Zheng]

Hi Savin,

1) I agree with you that add a new function 'CheckErasedBlock' to flash driver, flash driver might have better method to check the flash, I'll do it later.

2) Yes add uffs_BlockInfoInitErased() function will avoid unnecessary tag reading, I've applied your patch (I made a small tweak on your patch), thanks !

Cheers,

Ricky.

--
You received this message because you are subscribed to the Google Groups "UFFS" group.
To post to this group, send email to uf...@googlegroups.com.
To unsubscribe from this group, send email to uffs+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/uffs?hl=en.

[Savin Zlobec]

Hi Ricky,

On 01/03/2013 01:26 PM, Ricky Zheng wrote:
> Hi Savin,
>
> 1) I agree with you that add a new function 'CheckErasedBlock' to flash
> driver, flash driver might have better method to check the flash, I'll
> do it later.
> 2) Yes add uffs_BlockInfoInitErased() function will avoid unnecessary
> tag reading, I've applied your patch (I made a small tweak on your
> patch), thanks !

Ok, thanks.

I am looking at the read performance right now and I see that
sequential file read across one block first reads block tags
from last-->first and than reads pages from first-->last.
The first read (last->first) comes from uffs_FindBestPageInBlock,
can we apply the following optimization?

> ...
> u16 lastPage = dev->attr->pages_per_block - 1;
> ...
> if (page == lastPage) // already the last page ?
> return page;
>
> // Get last page in block and check if the block is fully
> // loaded, in which case there is no better page number
>
> uffs_BlockInfoLoad(dev, bc, lastPage);
> tag = GET_TAG(bc, lastPage);
>
> if (TAG_IS_GOOD(tag) && TAG_PAGE_ID(tag) == lastPage)
> return page;
>
> for (i = dev->attr->pages_per_block - 1; i > page; i--) {
> ...

This by itself doesn't reduce sequential read ops, but it makes
specific page tag and data reads one after another (so page 0 tag,
page 0 data, page 1 tag, page 1 data, ...). The driver can easily
optimize this by avoiding repeated flash array to flash cache buffer
transfers the second time and use random read from existing data
in flash cache buffer. Although it probably won't make a big difference
unless one has a very fast flash to memory transfer (compared to
internal flash read time).