From: "Josh Boyer" <jwboyer@gmail.com>
To: "Jared Hulbert" <jaredeh@gmail.com>
Cc: "Arnd Bergmann" <arnd@arndb.de>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Advanced XIP File System
Date: Tue, 2 May 2006 21:27:17 -0500 [thread overview]
Message-ID: <625fc13d0605021927l30ed3f86v48ad8fec9ec36051@mail.gmail.com> (raw)
In-Reply-To: <6934efce0605021859u55131e63xd8dab3d4396d7f56@mail.gmail.com>
On 5/2/06, Jared Hulbert <jaredeh@gmail.com> wrote:
> > Nice, this is the first time I heard of anyone using filemap_xip on MTD.
>
> Actually we don't use the MTD. Well, we may use it to provide the
> physical address of the volume, thats not really _using_ it.
Can you explain a bit more? If you aren't going to use the MTD, why
rely on it at all?
> >> - Design allows for tighter packing of data and higher performance
> >> than XIP cramfs
> >
> > why? by how much?
>
> Data packing:
> 1) When mkcramfs is writing files to the image it mixes compress and
> XIP files. XIP files are page aligned. Compressed files are not. I
> think it was about 3.3% wasted I measured on an actual production
> linux phone.
> 2) Choosing page by page to XIP or compress means you can save space,
> but it depends on what is more precious, RAM or Flash, given real
> designs (ie - you don't buy 36MiB of RAM you get 32MiB or 64MiB)
>
> Performance:
> 1) The way we are storing the metadata should make for quicker access.
> 2) Being able to store specific pages of RO data from an otherwise XIP
> file such that they end up in RAM has speed thing up for us a great
> deal in the lab.
Have you done comparisons vs. squashfs at all? It does better at both
performance and compression that cramfs, so I'm curious.
josh
next prev parent reply other threads:[~2006-05-03 2:27 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-02 21:53 Jared Hulbert
2006-05-03 0:00 ` Arnd Bergmann
2006-05-03 1:59 ` Jared Hulbert
2006-05-03 2:27 ` Josh Boyer [this message]
2006-05-03 5:04 ` Jared Hulbert
2006-05-03 8:31 ` David Woodhouse
2006-05-03 19:14 ` Pavel Machek
2006-05-04 16:32 ` Jared Hulbert
2006-05-03 0:56 ` Josh Boyer
2006-05-03 3:17 ` Nicolas Pitre
2006-05-03 10:41 ` Josh Boyer
2006-05-03 12:11 ` David Woodhouse
2006-05-03 15:45 ` Jared Hulbert
2006-05-03 15:52 ` David Woodhouse
2006-05-03 15:57 ` Nicolas Pitre
2006-05-03 16:01 ` David Woodhouse
2006-05-03 16:10 ` Nicolas Pitre
2006-05-03 5:11 ` Jared Hulbert
2006-05-03 12:50 ` Mark Lord
2006-05-03 15:33 ` Jared Hulbert
2006-05-03 13:05 ` Jörn Engel
2006-05-03 15:31 ` Jared Hulbert
2006-05-03 15:47 ` Jörn Engel
2006-05-03 15:58 ` Jared Hulbert
2006-05-03 17:03 ` Jörn Engel
2006-05-03 18:58 ` Jared Hulbert
2006-05-03 16:38 ` Jan Engelhardt
2006-05-03 18:54 ` Jared Hulbert
2006-05-03 23:17 ` Josh Boyer
2006-05-03 23:48 ` Jared Hulbert
2006-05-04 0:21 ` Josh Boyer
2006-05-03 22:49 ` David Woodhouse
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=625fc13d0605021927l30ed3f86v48ad8fec9ec36051@mail.gmail.com \
--to=jwboyer@gmail.com \
--cc=arnd@arndb.de \
--cc=jaredeh@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®