Re: Can jffs2 support XIP extensions?

[Todd Poynor <tpoynor@mvista.com>]

David Woodhouse wrote:

> If you really really really care about power, then you might care that
> RAM actually takes more power at runtime than flash does. But then we'd
> just laugh at you for using Linux instead of something much smaller and
> in particular without a periodic timer tick :)

A debate of the merits of various OS technologies for battery-powered 
portable devices would be interesting, but a number of awfully bright 
product designers are choosing Linux for *some* reason. ;)  Makers of 
cell phones do really really care about power.  And periodic timer ticks 
are being worked on (such as the Variable Scheduling Timeouts technology 
of George Anzinger's High Res Timers project).

> The only reason for using XIP under Linux which is even vaguely sane is
> to improve boot time. But since the figures shown at OLS were comparing
> apples and oranges -- compressed non-XIP kernel vs. uncompressed XIP
> kernel, with a lot of the time taken being the actual decompression, I'm
> not entirely convinced. There may well be better alternatives, without
> the runtime and hardware overhead.

For the kernel boot time it's true that boot times tend to be dominated 
by the decompression step.  I measured this on a couple platforms at one 
point (some of my measurements may have been in the OLS presentation, 
not sure).  I didn't directly measure kernel boot times of an 
uncompressed non-XIP kernel, but would roughly guess an uncompressed 
non-XIP kernel would boot to /sbin/init in only about a few tens of 
milliseconds more time (I'm guessing about the increased time to copy an 
uncompressed tetx image to RAM) than an XIP kernel on a 266MHz PowerPC 
405LP, and 168MHz OMAP ARM 926T is probably similar (it seems to better 
deal with the cache effects).

Application startup times non-XIP vs. XIP, compared to either CramFS 
compressed or ROMFS uncompressed, can add up to a more significant 
savings -- about 2 seconds for a TinyX startup and app start in the 
configuration I tried.  I have more data on kernel boot time, 
application startup, system sizing, and runtime performance benchmarks 
that I can send to anyone interested.

And yes, lower-overhead alternative technologies to help reduce SDRAM 
needs and sub-second startup times for consumer electronics would be 
welcome and are the subject of various other projects...

-- 
Todd Poynor
MontaVista Software