From: Wolfgang Denk <wd@denx.de>
To: "Robert P. J. Day" <rpjday@mindspring.com>
Cc: Embedded Linux PPC list <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: loading the kernel and root FS separately from flash?
Date: Mon, 28 Jun 2004 12:48:17 +0200 [thread overview]
Message-ID: <20040628104822.6C3BFC109F@atlas.denx.de> (raw)
In-Reply-To: Your message of "Mon, 28 Jun 2004 06:19:36 EDT." <Pine.LNX.4.60.0406280615400.3259@localhost.localdomain>
In message <Pine.LNX.4.60.0406280615400.3259@localhost.localdomain> you wrote:
>
> it was more the response time from flash as opposed to RAM that was an
> issue for me. that's why i was asking about having the root FS loaded
> from flash into RAM at boot time. we'd probably be happy about
> sacrificing boot time response (copying all of the root FS into RAM)
> for better run time performance, although i don't know the differences
> in performance at the moment.
Where is your ramdisk image coming from? Being loaded from flash?
So what's the difference between loading the image as a whole before
startup, or loading the files step by step when needed? If you need
everything in your ramdisk the difference in time is very small
(except from measurable changes in the start-up sequence, wher eyou
can have the first code running actually faster from a flash based
filesystem); if you don't use all the stuff in your ramdisk all the
time than the flash based filesystem may be faster, too.
We got the fastest boot and run times using a read-only ext2 file-
system in a MTD partition.
And using an overlay mounto to a JFFS2 partition you can still update
the files. [Or, for occasional updates, you can remount rw the
filesystem, perform the updates, and remount ro again - an ext2
filesystem on a flash partition is obviously not optimal, but if you
just need to change 2 files every year or so it will still work
fine.]
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
"An open mind has but one disadvantage: it collects dirt."
- a saying at RPI
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-06-28 10:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-27 22:46 loading the kernel and root FS separately from flash? Robert P. J. Day
2004-06-28 3:58 ` Eugene Surovegin
2004-06-28 10:00 ` Robert P. J. Day
2004-06-28 7:09 ` Wolfgang Denk
2004-06-28 9:42 ` David Woodhouse
2004-06-28 10:19 ` Robert P. J. Day
2004-06-28 10:48 ` Wolfgang Denk [this message]
2004-06-28 10:52 ` Robert P. J. Day
2004-06-28 10:23 ` Robert P. J. Day
2004-06-28 10:36 ` Wolfgang Denk
2004-06-28 10:40 ` David Woodhouse
2004-06-28 10:13 ` Robert P. J. Day
2004-06-28 10:41 ` Wolfgang Denk
2004-06-28 10:50 ` Robert P. J. Day
2004-06-29 9:31 ` David Woodhouse
2004-06-29 12:09 ` Robert P. J. Day
-- strict thread matches above, loose matches on Subject: below --
2004-06-28 11:33 Gerhard TAEUBL
[not found] <s0e01d9a.092@mail.frequentis.com>
2004-06-28 12:11 ` Robert P. J. Day
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=20040628104822.6C3BFC109F@atlas.denx.de \
--to=wd@denx.de \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=rpjday@mindspring.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;
as well as URLs for NNTP newsgroup(s).