Can jffs2 support XIP extensions?

Can jffs2 support XIP extensions?

[Christopher M Bergeron]

Does anyone know if jffs2 can utilize/support XIP (eXecute In Place)?  
I've read that only CramFS can work wit it.  I'm a little unclear about 
how XIP works and it's implications with jffs2 / CramFS.
Can anyone shed any light on this for me?

Much thanks in advance...
Chris B.


P.S.
Thanks for the replies re: my CVS question (and ipv6).  I was hoping 
that ipv4 would have been restored by now, but I think this will give me 
the excuse to finally upgrade to ipv6.  Also, thanks for the howto link 
David...!

Re: Can jffs2 support XIP extensions?

[David Woodhouse]

On Tue, 2004-08-24 at 10:43 -0400, Christopher M Bergeron wrote:
> Does anyone know if jffs2 can utilize/support XIP (eXecute In Place)?  
> I've read that only CramFS can work wit it.  I'm a little unclear about 
> how XIP works and it's implications with jffs2 / CramFS.
> Can anyone shed any light on this for me?

If you want Linux rather than something smaller, like eCos, then you
almost certainly don't want XIP.

XIP is for obvious reasons mutually exclusive with compression. You
throw away flash space in order to save RAM and to make data and code
access by the CPU slower.

Flash is more expensive than RAM -- your board will be cheaper if you
use half the flash and compress its contents, than it would be if you
use half the _RAM_ and XIP instead.

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 :)

In order to use XIP, you muck with the MMU to make mmap() of files on
the file system actually set up page tables to point at the flash chip.
You then have to care a lot about leaving the flash chip in read mode at
all times when userspace might be looking at it. 

Because cramfs is a read-only file system, it's easy enough to do this.
The files which are marked for XIP are carefully arranged so that each
logical page is physically page-aligned on the medium to allow the MMU
to map it. It would be a lot harder to achieve that in JFFS2, and
largely pointless. 

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.

-- 
dwmw2

Re: Can jffs2 support XIP extensions?

[Christopher M Bergeron]

Unfortunately, boot time is my primary concern.  However, I'm planning 
on booting an uncompressed linux kernel which should save quite a bit of 
boot time.  I'd be curious to know how much of an improvement is gained 
by using XIP in an uncompressed kernel without XIP - versus - 
uncompressed kernel _with_ XIP.

I would tend to think the difference is quite small, or OLS wouldn't 
have benchmarked with a compressed kernel against an uncompressed one.  
I think I'll steer clear of XIP for now...

Since we're on the topic, does anyone have any pointers, website links 
or kernel patches that have tips on accelerating kernel boot time?

Thanks!
-CB



David Woodhouse wrote:

>On Tue, 2004-08-24 at 10:43 -0400, Christopher M Bergeron wrote:
>  
>
>>Does anyone know if jffs2 can utilize/support XIP (eXecute In Place)?  
>>I've read that only CramFS can work wit it.  I'm a little unclear about 
>>how XIP works and it's implications with jffs2 / CramFS.
>>Can anyone shed any light on this for me?
>>    
>>
>
>If you want Linux rather than something smaller, like eCos, then you
>almost certainly don't want XIP.
>
>XIP is for obvious reasons mutually exclusive with compression. You
>throw away flash space in order to save RAM and to make data and code
>access by the CPU slower.
>
>Flash is more expensive than RAM -- your board will be cheaper if you
>use half the flash and compress its contents, than it would be if you
>use half the _RAM_ and XIP instead.
>
>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 :)
>
>In order to use XIP, you muck with the MMU to make mmap() of files on
>the file system actually set up page tables to point at the flash chip.
>You then have to care a lot about leaving the flash chip in read mode at
>all times when userspace might be looking at it. 
>
>Because cramfs is a read-only file system, it's easy enough to do this.
>The files which are marked for XIP are carefully arranged so that each
>logical page is physically page-aligned on the medium to allow the MMU
>to map it. It would be a lot harder to achieve that in JFFS2, and
>largely pointless. 
>
>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.
>
>  
>

Re: Can jffs2 support XIP extensions?

[George G. Davis]

On Tue, Aug 24, 2004 at 02:27:01PM -0400, Christopher M Bergeron wrote:
<snip>
> Since we're on the topic, does anyone have any pointers, website links 
> or kernel patches that have tips on accelerating kernel boot time?

http://tree.celinuxforum.org/pubwiki/moin.cgi/BootupTimeWorkingGroup

<snip>

--
Regards,
George

Re: Can jffs2 support XIP extensions?

[Todd Poynor]

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

Re: Can jffs2 support XIP extensions?

[Joshua Wise]

> 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).
Also remember that on many systems, flash is a lot slower than RAM, so 
it is entirely possible that an XIP kernel would actually be _SLOWER_ 
than non-XIP!

joshua

Re: Can jffs2 support XIP extensions?

[Der Herr Hofrat]

> > 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).
> Also remember that on many systems, flash is a lot slower than RAM, so 
> it is entirely possible that an XIP kernel would actually be _SLOWER_ 
> than non-XIP!
>
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)

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).

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

Re: Can jffs2 support XIP extensions?

[Todd Poynor]

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