NoiseEHC at freemail.hu
Thu Jun 4 03:36:40 EDT 2009
>> The kernel init improvements will certainly bring 15 other seconds.
>> Maybe some parallelisation of the sysvinit will save some time, say 5
>> seconds (low end estimation)
> Parallelization will not help at all if you are using JFFS2. The low
> level NAND driver that JFFS2 uses busy waits for I/O, and then JFFS2 is
> CPU-bound on the decompression step, preventing any useful concurrency.
> The busy-wait could be changed to an interrupt - if only someone had
> time to do the work and test it extensively. The decompression is going
> to be CPU bound no matter what you do, so the only option is to arrange
> for the important files not to be compressed (thus increasing the NAND
What I have been told: The busy waiting happens because there is no
scatter-gather support in the NAND driver so the interrupt rate is high
and it is faster to busy wait than to context switch. Probably it would
help to interrupt for large IO and busy wait for small IO but it needs
I promise you that if you happen to make the required efforts to speed
up booting then I will finish my fixed LZO decompressor code. It would
make reading compressed files actually faster, just I am not a Linux
kernel developer so integrating that with Linux would be your job.
BTW why the doctors cannot just close the lid and open when needed?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel