Limited support of NAND features in MTD.

Limited support of NAND features in MTD.

[Alexey Korolev]

Hi,

It is not a secret that current MTD supports very limited set of NAND
features. Some of missed features like partial page read or cached read
are able to improve file system performance and its implementation do
not require s/w redesign. 

I have a question is there any limitations/restrictions to support extended features? 
Does it make sense to implement these features and manage them
through nand_chip->options flag, letting people to choose whether to use
features or not? If it is not a good idea what is the best way to manage
it?

Currently my clooeague and I did prototypes of partial page read and cached read 
functionalities showing performance increase. For example partial page read showed about 20%
of file open/stat time performance increase in JFFS2 on LP NAND. Cached
read increases overall read performance but value strongly depends on
platform IO latencies. Now we are thinking to create and sent patches.

So your suggestions/recomendations are welcome!

Thanks,
Alexey 

Re: Limited support of NAND features in MTD.

[Artem Bityutskiy]

On Wed, 2007-12-12 at 11:51 +0000, Alexey Korolev wrote:
> It is not a secret that current MTD supports very limited set of NAND
> features. Some of missed features like partial page read or cached read
> are able to improve file system performance and its implementation do
> not require s/w redesign. 
> 
> I have a question is there any limitations/restrictions to support extended features? 

I do not think so. And it depends on the feature.

For example, partial flash read should not be a problem. If the driver
is asked to read only the first half of the NAND page, and it is capable
of partial page read, it reads only half the page. But nand_base.c would
need to be improved for this.

> Does it make sense to implement these features and manage them
> through nand_chip->options flag, letting people to choose whether to use
> features or not? If it is not a good idea what is the best way to manage
> it?

It again depends on the feature. These partial reads should be
transparent I think.

In general, it is worth trying hard not to introduce new interfaces. And
I think nand_chip structure should be accessed only by NAND
infrastructure.

> Currently my clooeague and I did prototypes of partial page read and cached read 
> functionalities showing performance increase. For example partial page read showed about 20%
> of file open/stat time performance increase in JFFS2 on LP NAND. Cached
> read increases overall read performance but value strongly depends on
> platform IO latencies. Now we are thinking to create and sent patches.

Sounds interesting.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: Limited support of NAND features in MTD.

[Josh Boyer]

On Wed, 12 Dec 2007 11:51:40 +0000 (GMT)
Alexey Korolev <akorolev@infradead.org> wrote:

> Hi,
> 
> It is not a secret that current MTD supports very limited set of NAND
> features. Some of missed features like partial page read or cached read
> are able to improve file system performance and its implementation do
> not require s/w redesign. 
> 
> I have a question is there any limitations/restrictions to support extended features? 
> Does it make sense to implement these features and manage them
> through nand_chip->options flag, letting people to choose whether to use
> features or not? If it is not a good idea what is the best way to manage
> it?
> 
> Currently my clooeague and I did prototypes of partial page read and cached read 
> functionalities showing performance increase. For example partial page read showed about 20%
> of file open/stat time performance increase in JFFS2 on LP NAND. Cached
> read increases overall read performance but value strongly depends on
> platform IO latencies. Now we are thinking to create and sent patches.
> 
> So your suggestions/recomendations are welcome!

Here is my suggestion.  Create the patches and send them :).

More seriously, it is often better to send out patches to show more
concretely what you'd like to accomplish.  Then people can review them
and make suggestions for improvements or changes.  I personally find it
rewarding to do so even if my patches aren't excepted in the end.  I
always learn something, and the code is archived for those that want to
play with it.

josh

Re: Limited support of NAND features in MTD.

[Alexey Korolev]

Hi Josh,

> Here is my suggestion.  Create the patches and send them :).
>
> More seriously, it is often better to send out patches to show more
> concretely what you'd like to accomplish.  Then people can review them
> and make suggestions for improvements or changes.  I personally find it
> rewarding to do so even if my patches aren't excepted in the end.  I
> always learn something, and the code is archived for those that want to
> play with it.
> 
>
Ok let do in this way. 
So the following message will contain pre-ready patch.

Actually I can not completely agree with these sentences, it often makes
sense to get info about assumed design.

Thanks,
Alexey

Re: Limited support of NAND features in MTD.

[Jörn Engel]

On Wed, 12 December 2007 11:51:40 +0000, Alexey Korolev wrote:
> 
> It is not a secret that current MTD supports very limited set of NAND
> features. Some of missed features like partial page read or cached read
> are able to improve file system performance and its implementation do
> not require s/w redesign. 

What does cached read do?

Another feature that could become useful would be the on-chip copying.
With JFFS2 this is rare, but when doing GC or wear leveling in a fashion
that keeps certain alignments intact, it could improve performance.

Jörn

-- 
The cost of changing business rules is much more expensive for software
than for a secretaty.
-- unknown

Re: Limited support of NAND features in MTD.

[Alexey Korolev]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1006 bytes --]

Hi Jörn

> > 
> > It is not a secret that current MTD supports very limited set of NAND
> > features. Some of missed features like partial page read or cached read
> > are able to improve file system performance and its implementation do
> > not require s/w redesign. 
> 
> What does cached read do?
> 
Performs cached read operations :). It is a feature of NAND devices. It increases performance if we have 
request to read sequentally large amount of data from NAND. 

> Another feature that could become useful would be the on-chip copying.
> With JFFS2 this is rare, but when doing GC or wear leveling in a fashion
> that keeps certain alignments intact, it could improve performance.
>
Yeah. I know this feature. If I properly understand the real purpose of
it is mostly related for FTL but could be used for FS as well. 
You are right it make sense to try it. But I do not know when it will be possible to do 
this. Usually this feature is called as Internal data move in NAND specs. 

Thanks,
Alexey

Re: Limited support of NAND features in MTD.

[Jörn Engel]

On Tue, 18 December 2007 15:06:50 +0000, Alexey Korolev wrote:
> > 
> > What does cached read do?
> > 
> Performs cached read operations :)

Who would have thought? :)

> It is a feature of NAND devices. It increases performance if we have 
> request to read sequentally large amount of data from NAND. 

Do you have a little more information on this?  Where does the cache
reside?  How big is it?  Who controls it?  How does it interact with
writes? ...

Possibly the best answer would be a link to a datasheet.

> > Another feature that could become useful would be the on-chip copying.
> > With JFFS2 this is rare, but when doing GC or wear leveling in a fashion
> > that keeps certain alignments intact, it could improve performance.
> >
> Yeah. I know this feature. If I properly understand the real purpose of
> it is mostly related for FTL but could be used for FS as well. 
> You are right it make sense to try it. But I do not know when it will be possible to do 
> this. Usually this feature is called as Internal data move in NAND specs. 

At least I would like to know what the conditions are.  Can the command
copy whole blocks only?  If it can copy single pages, can it copy any
pages or just the Nth page of one block to the Nth page of another?

If any page can be copied to any other page, it should be quite useful
for any non-compressed filesystem.  YAFFS, old LogFS, anything that does
XIP, possibly UBI,...

Jörn

-- 
Joern's library part 7:
http://www.usenix.org/publications/library/proceedings/neworl/full_papers/mckusick.a

Re: Limited support of NAND features in MTD.

[Alexey Korolev]

Hi
> On Tue, 18 December 2007 15:06:50 +0000, Alexey Korolev wrote:
> > > 
> > > What does cached read do?
> > > 
> > Performs cached read operations :)
> 
> Who would have thought? :)
> 
> > It is a feature of NAND devices. It increases performance if we have 
> > request to read sequentally large amount of data from NAND. 
> 
> Do you have a little more information on this?  Where does the cache
> reside?  How big is it?  Who controls it?  How does it interact with
> writes? ...
>
Ok. Alexander will send more detailed info now.  
> Possibly the best answer would be a link to a datasheet.
> 
Ok. Just a second I will try to find a link to an open datasheet. 
Thanks,
Alexey

Re: Limited support of NAND features in MTD.

[Alexander Belyakov]

On Dec 18, 2007 5:23 PM, Jörn Engel <joern@logfs.org> wrote:
>
> What does cached read do?
>

Some NAND chips have PAGE READ CACHE MODE operation
that uses the cache register to read data. The basic idea is as
follows: a page of data is transferred from the Flash array to the
data register and moved to the cache register when the PAGE READ
CACHE MODE command is issued. After this command is issued, data can
be clocked out of the cache register through the NAND Flash interface,
while the next page of data is simultaneously moved from the Flash
array to the data register.

So PAGE READ CACHE MODE operation saves time to read
each page. Pages must be sequentially read one by one without
interruption. The more pages read sequentially, the more read performance
improvement is (with saturation, of course).

Alexander

Re: Limited support of NAND features in MTD.

[Alexey Korolev]

Hi

> Possibly the best answer would be a link to a datasheet.

>> Yeah. I know this feature. If I properly understand the real purpose
>> of
>> it is mostly related for FTL but could be used for FS as well. 
>> You are right it make sense to try it. But I do not know when it will
>> be possible to do 
>> this. Usually this feature is called as Internal data move in NAND
>> specs. 

> At least I would like to know what the conditions are.  Can the
> command
> copy whole blocks only?  If it can copy single pages, can it copy any
> pages or just the Nth page of one block to the Nth page of another?

> If any page can be copied to any other page, it should be quite useful
> for any non-compressed filesystem.  YAFFS, old LogFS, anything that
> does
> XIP, possibly UBI,...

I think those links will describe internal data move well.

http://download.micron.com/pdf/technotes/nand/tn2915.pdf 
http://www.st.com/stonline/products/literature/an/10061.htm 

Here is a link about cached read in addition to Alexander's description. 
http://download.micron.com/pdf/technotes/nand/tn2901.pdf 

Thanks,
Alexey

Re: Limited support of NAND features in MTD.

[Jörn Engel]

On Tue, 18 December 2007 08:57:58 -0800, David Brown wrote:
> 
> One problem with the on-chip copy is that ECC doesn't get corrected.  If
> there are errors on readback, it will get written that way, and errors
> would accumulate.

Ouch!  Such an implementation would indeed make this whole business
pointless.

> It is conceivable that the controller could do something intermediary, such
> as read the data, and if the ECC needs no correction, write from the
> on-chip cache, otherwise write the corrected data.

Yes, something like that would be necessary.

Jörn

-- 
To my face you have the audacity to advise me to become a thief - the worst
kind of thief that is conceivable, a thief of spiritual things, a thief of
ideas! It is insufferable, intolerable!
-- M. Binet in Scarabouche

Re: Limited support of NAND features in MTD.

[David Brown]

On Tue, Dec 18, 2007 at 04:18:01PM +0100, Jörn Engel wrote:

>> Yeah. I know this feature. If I properly understand the real purpose of
>> it is mostly related for FTL but could be used for FS as well. 
>> You are right it make sense to try it. But I do not know when it will be possible to do 
>> this. Usually this feature is called as Internal data move in NAND specs. 
>
>At least I would like to know what the conditions are.  Can the command
>copy whole blocks only?  If it can copy single pages, can it copy any
>pages or just the Nth page of one block to the Nth page of another?

One problem with the on-chip copy is that ECC doesn't get corrected.  If
there are errors on readback, it will get written that way, and errors
would accumulate.

It is conceivable that the controller could do something intermediary, such
as read the data, and if the ECC needs no correction, write from the
on-chip cache, otherwise write the corrected data.

Dave

Re: Limited support of NAND features in MTD.

[David Woodhouse]

On Tue, 2007-12-18 at 17:56 +0100, Jörn Engel wrote:
> On Tue, 18 December 2007 08:57:58 -0800, David Brown wrote:
> > 
> > One problem with the on-chip copy is that ECC doesn't get corrected.  If
> > there are errors on readback, it will get written that way, and errors
> > would accumulate.
> 
> Ouch!  Such an implementation would indeed make this whole business
> pointless.

That's fairly much been my conclusion every time I've looked at the new
features we haven't yet bothered to support. Partial page read also
suffers from lack of ECC.

-- 
dwmw2

Re: Limited support of NAND features in MTD.

[Alexey Korolev]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 723 bytes --]

Hi David,
> 
> On Tue, 2007-12-18 at 17:56 +0100, Jörn Engel wrote:
> > On Tue, 18 December 2007 08:57:58 -0800, David Brown wrote:
> > > 
> > > One problem with the on-chip copy is that ECC doesn't get corrected.  If
> > > there are errors on readback, it will get written that way, and errors
> > > would accumulate.
> > 
> > Ouch!  Such an implementation would indeed make this whole business
> > pointless.
> 
> That's fairly much been my conclusion every time I've looked at the new
> features we haven't yet bothered to support. Partial page read also
> suffers from lack of ECC.
Hmm I did not heard about this. Could you please give more details on how 
partial page read can suffer from lack of ECC?

Thanks,
Alexey

Re: Limited support of NAND features in MTD.

[David Woodhouse]

On Wed, 2007-12-19 at 10:49 +0000, Alexey Korolev wrote:
> Hmm I did not heard about this. Could you please give more details on
> how partial page read can suffer from lack of ECC?

If your ECC covers the whole page, you have to read the whole page in
order to check ECC.

Of course, if you do ECC in sub-pages in the first place, you can read
only a single ECC block. But you still can't just read arbitrary byte
ranges.

-- 
dwmw2

Re: Limited support of NAND features in MTD.

[Alexey Korolev]

Hi
> 
> On Wed, 2007-12-19 at 10:49 +0000, Alexey Korolev wrote:
> > Hmm I did not heard about this. Could you please give more details on
> > how partial page read can suffer from lack of ECC?
> 
> If your ECC covers the whole page, you have to read the whole page in
> order to check ECC.
> 
> Of course, if you do ECC in sub-pages in the first place, you can read
> only a single ECC block. But you still can't just read arbitrary byte
> ranges.
> 
It seems misunderstaning takes place here. Under partial/subpage page read we understand reading block of data covered by ECC. It means if we request to read 40bytes - we will read data equal to ECC step (it could be 256 bytes or 512bytes -depending on boundary conditions, but not 2048/4096 bytes in case of whole page read). If we have MLC NAND with whole page covered by ECC partial/subpage page read will be equivalent to page read. 

P/S
If partial page read name cause misunderstanding will subpage read name be obvious enough?

Thanks,
Alexey

Re: Limited support of NAND features in MTD.

[Artem Bityutskiy]

On Wed, 2007-12-19 at 10:52 +0000, David Woodhouse wrote:
> On Wed, 2007-12-19 at 10:49 +0000, Alexey Korolev wrote:
> > Hmm I did not heard about this. Could you please give more details on
> > how partial page read can suffer from lack of ECC?
> 
> If your ECC covers the whole page, you have to read the whole page in
> order to check ECC.
> 
> Of course, if you do ECC in sub-pages in the first place, you can read
> only a single ECC block. But you still can't just read arbitrary byte
> ranges.

Sure, but as the guys showed, even this gives substantial JFFS2
performance growth. Providing their figures are correct, subpage reads
are more then worth using.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: Limited support of NAND features in MTD.

[David Woodhouse]

On Wed, 2007-12-19 at 13:57 +0200, Artem Bityutskiy wrote:
> On Wed, 2007-12-19 at 10:52 +0000, David Woodhouse wrote:
> > On Wed, 2007-12-19 at 10:49 +0000, Alexey Korolev wrote:
> > > Hmm I did not heard about this. Could you please give more details on
> > > how partial page read can suffer from lack of ECC?
> > 
> > If your ECC covers the whole page, you have to read the whole page in
> > order to check ECC.
> > 
> > Of course, if you do ECC in sub-pages in the first place, you can read
> > only a single ECC block. But you still can't just read arbitrary byte
> > ranges.
> 
> Sure, but as the guys showed, even this gives substantial JFFS2
> performance growth. Providing their figures are correct, subpage reads
> are more then worth using.

Yeah, that part makes sense.

-- 
dwmw2