From: Matthias Kaehlcke <matthias@kaehlcke.net>
To: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: initramfs optimization suggestions
Date: Tue, 5 Aug 2008 10:39:46 +0200 [thread overview]
Message-ID: <20080805083946.GC3165@traven> (raw)
In-Reply-To: <ac9c93b10808050042u496bfa10nad7962eb0e9ec015@mail.gmail.com>
Hi Frans
El Tue, Aug 05, 2008 at 09:42:11AM +0200 Frans Meulenbroeks ha dit:
> [Upfront apologies if this is the wrong place to post this to.Just
> give me a gentle redirect to the right place in that case.]
>
> I've been looking into improving the boot time of an embedded linux
> system (monta vista based).
> While doing so I detected that initramfs initialisation was one of the
> places where a lot of time was spent, so I looked into it in some more
> detail and came up with the following findings & suggestions.
>
> First proposal:
> ==========
>
> initramfs is build from a compressed cpio archive.
> Proposal is to introduce a build option to make the compression and
> decompression optional.
> Rationale 1: could be faster as it trades off I/O time (to read the
> image) against decompression time
> Rationale 2: for architectures that use compressed images (bzImage)
> actually we compress twice, which is not really efficient.
>
> I can implement this, but before spending time on it I would like to know if
> a) people consider this a good idea
> b) no one else already has doen this.
>
>
> Second proposal:
> ============
>
> after decompressing the cpio archive all files are made using
> sys_open/sys_write/sys_close and friends.
> This implies that a lot of system calls and data copying is done.
> It would be nice if that could be avoided.
> I'm not fully into all details of how ramfs is implemented, but would
> it be possible to e.g. dump all blocks of a tmp ram fs into a data
> structure (e.g.an array of blocks) while making the kernel, and while
> booting the kernel initialise the fs cache with these data? (I guess
> this would be around fs/dcache.c; I understand the data here is
> kmalloc-ed, but it might be possible to initialise the cache with
> pointers to that data structure; due to the nature of ramfs they won't
> be deallocated anyway I assume).
> Does this sound feasible? Hidden snags? Appreciate your
> opinion/feedback/suggestions.
>
> Best regards, Frans.
>
> PS: if anyone has a pointer to a place which explains in full detail
> how linux fs internally works (apart from the source :-) ) I
> appreciate a reference. FM
you might want to get in touch with Robert P. J. Day
(rpjday@crashcourse.ca>) who is also working on initramfs
optimizations. see a recent thread on the kernelnewbies mailing list:
http://article.gmane.org/gmane.linux.kernel.kernelnewbies/26978
--
Matthias Kaehlcke
Embedded Linux Engineer
Barcelona
You can chain me, you can torture me, you can even
destroy this body, but you will never imprison my mind
(Mahatma Gandhi)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
next prev parent reply other threads:[~2008-08-05 8:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-05 7:42 initramfs optimization suggestions Frans Meulenbroeks
2008-08-05 8:39 ` Matthias Kaehlcke [this message]
2008-08-07 0:25 ` H. Peter Anvin
2008-08-07 7:11 ` Frans Meulenbroeks
2008-08-07 17:28 ` H. Peter Anvin
2008-08-08 6:53 ` Frans Meulenbroeks
2008-08-08 10:06 ` Frans Meulenbroeks
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=20080805083946.GC3165@traven \
--to=matthias@kaehlcke.net \
--cc=fransmeulenbroeks@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