* Load UBI faster
@ 2009-05-06 7:26 simon polette
2009-05-07 5:22 ` Artem Bityutskiy
0 siblings, 1 reply; 6+ messages in thread
From: simon polette @ 2009-05-06 7:26 UTC (permalink / raw)
To: linux-mtd
Hi,
I'm trying to improve boot time on a at91sam9261ek board. I boot on
nand flash with ubifs. It take about 400ms to load ubi and ubifs.
Do you know if fastboot technology, which consist in loading drivers
asynchronously, is conceivable with UBI ?
Thanks for your help.
Best regards.
Simon P.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Load UBI faster
2009-05-06 7:26 Load UBI faster simon polette
@ 2009-05-07 5:22 ` Artem Bityutskiy
2009-05-07 5:28 ` Artem Bityutskiy
0 siblings, 1 reply; 6+ messages in thread
From: Artem Bityutskiy @ 2009-05-07 5:22 UTC (permalink / raw)
To: simon polette; +Cc: linux-mtd
On Wed, 2009-05-06 at 09:26 +0200, simon polette wrote:
> I'm trying to improve boot time on a at91sam9261ek board. I boot on
> nand flash with ubifs. It take about 400ms to load ubi and ubifs.
> Do you know if fastboot technology, which consist in loading drivers
> asynchronously, is conceivable with UBI ?
> Thanks for your help.
Fastbood is applicable in the situation when initialization
is mostly about sleeping and waiting for hw. In case of UBI,
it reads from flash and calculates CRC. The reading from NAND
is usuall synchronous, so this process takes 100% of your CPU.
One way to optimize this a little would be to use on-flash
BBT. Usually the nand core scans full NAND to find bad blocks.
With on-flash BBT this could be avoided. But probably this
would not give you much.
How big is your NAND?
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Load UBI faster
2009-05-07 5:22 ` Artem Bityutskiy
@ 2009-05-07 5:28 ` Artem Bityutskiy
2009-05-13 15:03 ` simon polette
0 siblings, 1 reply; 6+ messages in thread
From: Artem Bityutskiy @ 2009-05-07 5:28 UTC (permalink / raw)
To: simon polette; +Cc: linux-mtd
On Thu, 2009-05-07 at 08:22 +0300, Artem Bityutskiy wrote:
> On Wed, 2009-05-06 at 09:26 +0200, simon polette wrote:
> > I'm trying to improve boot time on a at91sam9261ek board. I boot on
> > nand flash with ubifs. It take about 400ms to load ubi and ubifs.
> > Do you know if fastboot technology, which consist in loading drivers
> > asynchronously, is conceivable with UBI ?
> > Thanks for your help.
>
> Fastbood is applicable in the situation when initialization
> is mostly about sleeping and waiting for hw. In case of UBI,
> it reads from flash and calculates CRC. The reading from NAND
> is usuall synchronous, so this process takes 100% of your CPU.
>
> One way to optimize this a little would be to use on-flash
> BBT. Usually the nand core scans full NAND to find bad blocks.
> With on-flash BBT this could be avoided. But probably this
> would not give you much.
You could also play with CRC. ATM we use CRC32 for UBI headers.
This is rather expensive if you CPU is slow. I'd try to hack
UBI and see what changes if it does not calculate it. If it
helps, you could try to consider CRC16 or adler32 instead of
CRC32.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Load UBI faster
2009-05-07 5:28 ` Artem Bityutskiy
@ 2009-05-13 15:03 ` simon polette
2009-05-13 20:10 ` Corentin Chary
2009-05-15 12:00 ` Artem Bityutskiy
0 siblings, 2 replies; 6+ messages in thread
From: simon polette @ 2009-05-13 15:03 UTC (permalink / raw)
To: dedekind; +Cc: linux-mtd, spolette
My NAND is 256MB but I use only a 130MB partition for UBI/UBIFS.
So I implemented the on-flash BBT, that made me save 120ms which is a
sizeable improvement.
On the other hand, skipping crc calculation for header doesn't seem to
save much time (perhaps ~10ms so it's difficult to measure the
difference).
Best regards,
Simon Polette
ADENEO
2009/5/7 Artem Bityutskiy <dedekind@infradead.org>:
> On Thu, 2009-05-07 at 08:22 +0300, Artem Bityutskiy wrote:
>> On Wed, 2009-05-06 at 09:26 +0200, simon polette wrote:
>> > I'm trying to improve boot time on a at91sam9261ek board. I boot on
>> > nand flash with ubifs. It take about 400ms to load ubi and ubifs.
>> > Do you know if fastboot technology, which consist in loading drivers
>> > asynchronously, is conceivable with UBI ?
>> > Thanks for your help.
>>
>> Fastbood is applicable in the situation when initialization
>> is mostly about sleeping and waiting for hw. In case of UBI,
>> it reads from flash and calculates CRC. The reading from NAND
>> is usuall synchronous, so this process takes 100% of your CPU.
>>
>> One way to optimize this a little would be to use on-flash
>> BBT. Usually the nand core scans full NAND to find bad blocks.
>> With on-flash BBT this could be avoided. But probably this
>> would not give you much.
>
> You could also play with CRC. ATM we use CRC32 for UBI headers.
> This is rather expensive if you CPU is slow. I'd try to hack
> UBI and see what changes if it does not calculate it. If it
> helps, you could try to consider CRC16 or adler32 instead of
> CRC32.
>
> --
> Best regards,
> Artem Bityutskiy (Битюцкий Артём)
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Load UBI faster
2009-05-13 15:03 ` simon polette
@ 2009-05-13 20:10 ` Corentin Chary
2009-05-15 12:00 ` Artem Bityutskiy
1 sibling, 0 replies; 6+ messages in thread
From: Corentin Chary @ 2009-05-13 20:10 UTC (permalink / raw)
To: simon polette; +Cc: linux-mtd, spolette
2009/5/13 simon polette <spolette@gmail.com>:
> My NAND is 256MB but I use only a 130MB partition for UBI/UBIFS.
> So I implemented the on-flash BBT, that made me save 120ms which is a
> sizeable improvement.
> On the other hand, skipping crc calculation for header doesn't seem to
> save much time (perhaps ~10ms so it's difficult to measure the
> difference).
You can try playing with bootchart http://www.bootchart.org/ to be
sure that there is nothing else to change
during the boot process.
You can also try to get separate results to see what's taking time
(mtd, ubi, ubifs). CONFIG_FUNCTION_TRACER and CONFIG_BOOT_TRACER may
help you with that.
I'll do some test on the same hardware soon, maybe I'll be able to
help you more.
--
Corentin Chary
http://xf.iksaif.net - http://uffs.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Load UBI faster
2009-05-13 15:03 ` simon polette
2009-05-13 20:10 ` Corentin Chary
@ 2009-05-15 12:00 ` Artem Bityutskiy
1 sibling, 0 replies; 6+ messages in thread
From: Artem Bityutskiy @ 2009-05-15 12:00 UTC (permalink / raw)
To: simon polette; +Cc: linux-mtd, spolette
On Wed, 2009-05-13 at 17:03 +0200, simon polette wrote:
> My NAND is 256MB but I use only a 130MB partition for UBI/UBIFS.
> So I implemented the on-flash BBT, that made me save 120ms which is a
> sizeable improvement.
> On the other hand, skipping crc calculation for header doesn't seem to
> save much time (perhaps ~10ms so it's difficult to measure the
> difference).
Well, you could try profiling your system and see where you can
try to optimize things.
But I think the bottleneck is the flash reading. If you may
improve it - cool.
UBI has to scan the media, this is in it's design. You would
need to develop UBI2 to fix that:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_scalability
On thing you may do is to lessen the amount of eraseblocks by
joining your physical erasblocks on driver level, and report
eraseblock size 256KiB, instead of 128KiB. Then UBI would have
to read twice as less. But the drawback is that if one PEB is
bad, you waste its pair, which is not bad.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-05-15 12:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-06 7:26 Load UBI faster simon polette
2009-05-07 5:22 ` Artem Bityutskiy
2009-05-07 5:28 ` Artem Bityutskiy
2009-05-13 15:03 ` simon polette
2009-05-13 20:10 ` Corentin Chary
2009-05-15 12:00 ` Artem Bityutskiy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).