Re: Can jffs2 support XIP extensions?

[Todd Poynor <tpoynor@mvista.com>]

Der Herr Hofrat wrote:

> there are a number of examples of boot times and runtime performance posted
> on the web and ALL of them show that the boot times of XIP
> enabled kernels are primarily lower due to the kernel
> not being decompressed and other steps actually being slower.
> 
>    Table of bootup times:
> 
>    Boot Stage                         Non-XIP  Time XIP Time
>    Copy kernel to RAM                 85 ms    12 ms 
>    Decompress kernel                  453 ms   0 ms
>    Kernel time to initialize
>    (time to first user space program) 819 ms   882 ms
>    Total kernel boot time             1357 ms  894 ms
>    Reduction:                         -        463 ms
> 
> (from: http://tree.celinuxforum.org/pubwiki/moin.cgi/KernelXIP)

Yes, those are the numbers I measured on a PPC405LP.  The step of 
copying the necessary kernel image is also slower non-XIP, since XIP 
copies only the initialized data sections.  If an uncompressed non-XIP 
image is used then that particular number will increase, partially 
offseting the gain due to skipping the decompression.  Depending on the 
sizes involved XIP will likely be faster by a few tens or hundreds of 
milliseconds.  When combined with application XIP of several executables 
and shared libraries from a CramFS filesystem this can add up to a 
significant gain; if ROMFS is used to avoid compression then the 
difference is less but still significant.

> The execution times of most system calls are clearly longer (not sure if
> it was a 405/266 or a OMAP/168) fork was reported at 7.1 vs 4.8 us , trivial 
> system calls will be about the same time (did not find the reference - if of 
> interest I can dig it out).

Should be 7.1ms vs. 4.7ms, on OMAP (and 4.1ms vs. 1.1ms on PPC405LP, 
which seems to have a lower locality of reference or some other 
uninvestigated disadvantage running XIP).  I've got the full LMbench 
runs and some additional experimentation that produced those numbers as 
well.  The system will definitely run overall slower due to the slower 
memory, but certain operations such as the first exec of an image will 
be faster -- subsequent exec's of the same image may be as fast or 
faster after the block cache is warmed.

> The only (?) real argument for XIP is system RAM requirements on very small 
> systems (see: http://www.denx.de/twiki/publish/DULG/ConfigureLinuxForXIP.htm) 

System startup time reduction (including applications) is certainly a 
consideration as well.  After evaluating unit production cost, power 
consumption, startup time, and performance, some cell phone designers 
have chosen to go the XIP route, although no word on whether they'd 
choose it again the next time. ;)

-- 
Todd Poynor
MontaVista Software