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:41:54 +0200 [thread overview]
Message-ID: <20040628104159.87EEDC109F@atlas.denx.de> (raw)
In-Reply-To: Your message of "Mon, 28 Jun 2004 06:13:18 EDT." <Pine.LNX.4.60.0406280600140.3259@localhost.localdomain>
In message <Pine.LNX.4.60.0406280600140.3259@localhost.localdomain> you wrote:
>
> i suspect that leaving my root filesystem in flash would cause
> noticeable performance problems (even if i managed to structure it so
What makes you think so?
The startup behaviour may change: at the moment you load the whole
root filesystem into RAM before you can run anything at all - that
means it takes longer before the first application can start. But
then everything _is_ in RAM, so anything else will start quickly,
too.
With a flash based root filesystem only the things (binaries,
libraries) that are actually needed for the first user processes
(init etc.) will be loaded to RAM, so they may actually start faster
than from a RAM disk. But anything else may require to load
additional libraries etc. so it may start slower than from a ramdisk.
On the other hand, some code or binaries (like error handling stuff,
debug tools etc.) may not be loaded at all for normal operation, so
you will have more RAM free, which adds to speed, too.
> that it could be read-only). how hard would it be to automatically
> have that root FS copied from JFFS2 to RAM and mounted from there?
This makes just no sense to me.
> can that be done as a kernel option i haven't seen? or do i have to
> do that manually, involving something like "pivot_root"? or is it
> worth the trouble?
I cannot see any advantages from such a setup.
If you want a RAM based root filesystem, use a ramdisk.
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
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it on
the computer.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-06-28 10:41 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
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 [this message]
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=20040628104159.87EEDC109F@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).