Re: [U-Boot] [PATCH,V2] JFFS2: accelerate scanning.

2011-04-19 Thread Detlev Zundel
Hi Baidu,

>  Syncs up with jffs2 in the linux kernel:
>  1/ Change DEFAULT_EMPTY_SCAN_SIZE from 4KB to 256 Bytes.
>  2/ If the 1KB data is 0xFF after the cleanmarker, skip
>  and scan the next sector.
>  3/ Change the buffer size from 4KB to 128KB which is the
>  common size of erase block.

There is no "common size of erase block".  Looking into the Linux code,
it uses "max(erase block size, 128k)" for its buffer to speed up reading
from NAND and the 128k seem to be a kmalloc limit.

So maybe a "increase buffer size from 4KiB to 128KiB to reduce number of
read operations" would be more fitting.  By the way, does this change
contribute to the performance increase at all, or is the increase simply
due to DEFAULT_EMPTY_SCAN_SIZE?

Also as for the other patch, can you split the commit into the
individual changes corresponding to the list items?  In this way, one
could also easily measure which change really speeds up the operation...

Thanks!
  Detlev

-- 
It is practically impossible to teach good programming to students that have
had a  prior exposure to BASIC:  as potential  programmers they are mentally
mutilated beyond hope of regeneration.-- Edsger Dijkstra 
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH,V2] JFFS2: accelerate scanning.

2011-04-23 Thread Baidu Liu
Hi,Detlev :

2011/4/19 Detlev Zundel :
> Hi Baidu,
>
>>  Syncs up with jffs2 in the linux kernel:
>>  1/ Change DEFAULT_EMPTY_SCAN_SIZE from 4KB to 256 Bytes.
>>  2/ If the 1KB data is 0xFF after the cleanmarker, skip
>>  and scan the next sector.
>>  3/ Change the buffer size from 4KB to 128KB which is the
>>  common size of erase block.
>
> There is no "common size of erase block".  Looking into the Linux code,
> it uses "max(erase block size, 128k)" for its buffer to speed up reading
> from NAND and the 128k seem to be a kmalloc limit.
>
> So maybe a "increase buffer size from 4KiB to 128KiB to reduce number of
> read operations" would be more fitting.  By the way, does this change
> contribute to the performance increase at all, or is the increase simply
> due to DEFAULT_EMPTY_SCAN_SIZE?
>

Yes, I think it is useful to speed up the scanning.

I have split these changes to individual patch.
Thans.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH,V2] JFFS2: accelerate scanning.

2011-04-27 Thread Detlev Zundel
Hi Baidu,

> Hi,Detlev :
>
> 2011/4/19 Detlev Zundel :
>> Hi Baidu,
>>
>>>  Syncs up with jffs2 in the linux kernel:
>>>  1/ Change DEFAULT_EMPTY_SCAN_SIZE from 4KB to 256 Bytes.
>>>  2/ If the 1KB data is 0xFF after the cleanmarker, skip
>>>  and scan the next sector.
>>>  3/ Change the buffer size from 4KB to 128KB which is the
>>>  common size of erase block.
>>
>> There is no "common size of erase block".  Looking into the Linux code,
>> it uses "max(erase block size, 128k)" for its buffer to speed up reading
>> from NAND and the 128k seem to be a kmalloc limit.
>>
>> So maybe a "increase buffer size from 4KiB to 128KiB to reduce number of
>> read operations" would be more fitting.  By the way, does this change
>> contribute to the performance increase at all, or is the increase simply
>> due to DEFAULT_EMPTY_SCAN_SIZE?
>>
>
> Yes, I think it is useful to speed up the scanning.

Don't get me wrong, but I was not asking whether you "think" it speeds
up the scanning.  When it comes to performance, I learnt to trust
numbers olnly.  This may in part be because I myself occassionally was
completely wrong in predicting performance issues.

So I am still eager to see actual numbers if this _really_ speeds up
scanning.

Cheers
  Detlev

-- 
Die meisten schaetzen nicht, was sie verstehen; aber was sie nicht fassen
koennen, verehren sie.  Um geschaetzt zu werden, muessen die Sachen Muehe
kosten; daher wird geruehmt, wer nicht verstanden wird.
--- Baltasar Gracian
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot