public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Todd Poynor <tpoynor@mvista.com>
To: Tim Bird <tim.bird@am.sony.com>
Cc: colin <colin@realtek.com.tw>,
	David Woodhouse <dwmw2@infradead.org>,
	Paulo Marques <pmarques@grupopie.com>,
	linux-kernel@vger.kernel.org
Subject: Re: What File System supports Application XIP
Date: Fri, 10 Sep 2004 17:06:01 -0700	[thread overview]
Message-ID: <41424169.3020302@mvista.com> (raw)
In-Reply-To: <4140865A.5030304@am.sony.com>

Tim Bird wrote:
...
> The patches I've seen require setting the CRAMFS_LINEAR option, to turn on
> linear addressing for cramfs, and CRAMFS_LINEAR_XIP.  The result of these
> is to dispense with compression.

Compression is skipped for the XIP files, which are typically marked via 
the sticky bit.  You'll also need a version of mkcramfs that creates the 
image without compressing those files.

...
> FYI - Here are some rough numbers:
> Time to run shell script which starts TinyX X server and "xsetroot -solid red",
> then shuts down:
> 
> First invocation: Non-XIP 3.195 seconds, XIP 2.035 seconds
> Second invocation: Non-XIP 1.744 seconds, XIP 1.765 seconds
> 
> I think this was on a 133 MHz PPC, but I'm not positive.  In both cases
> the filesystem was in flash.  

It was measured on a 168MHz ARM 925T TI OMAP 1510.

Others' advice that "you probably don't want XIP" is true in most cases. 
  But in producing a battery-operated product with certain requirements 
for performance, power savings (due to reduced RAM requirements), 
startup time (depending on the platform and software stack the 
difference can be significant), etc. XIP is an option chosen by some CE 
designers, who are willing to accept the performance penalty on a 
product that will still run adequately for its intended uses.  It would 
be interesting to see an in-depth analysis of these topics on an actual 
Linux-based product such as a cell phone.  There are, of course, a 
number of ways to address all these issues, not just XIP...

-- 
Todd Poynor
MontaVista Software


  reply	other threads:[~2004-09-11  0:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-09  8:55 What File System supports Application XIP colin
2004-09-09  9:18 ` Arjan van de Ven
2004-09-09  9:45   ` colin
2004-09-09  9:53     ` Arjan van de Ven
2004-09-09 16:56       ` Tim Bird
2004-09-09 17:17         ` Arjan van de Ven
2004-09-09 17:38         ` Robert Love
2004-09-10  2:12           ` colin
2004-09-10  2:15             ` Robert Love
2004-09-09  9:19 ` Paulo Marques
2004-09-09  9:42   ` David Woodhouse
2004-09-09 16:35     ` Tim Bird
2004-09-11  0:06       ` Todd Poynor [this message]
2004-09-09  9:58   ` ¡@[*©U§£¶l¥ó*] " colin
2004-09-09 10:43 ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41424169.3020302@mvista.com \
    --to=tpoynor@mvista.com \
    --cc=colin@realtek.com.tw \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmarques@grupopie.com \
    --cc=tim.bird@am.sony.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox